hw/mips/mips_fulong2e.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
Do not create an ATI VGA if "-vga none" was passed on the command line.
Cc: BALATON Zoltan <balaton@eik.bme.hu>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
hw/mips/mips_fulong2e.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/hw/mips/mips_fulong2e.c b/hw/mips/mips_fulong2e.c
index 9d7480ed31..05a5a823a1 100644
--- a/hw/mips/mips_fulong2e.c
+++ b/hw/mips/mips_fulong2e.c
@@ -349,10 +349,12 @@ static void mips_fulong2e_init(MachineState *machine)
&smbus, &isa_bus);
/* GPU */
- dev = DEVICE(pci_create(pci_bus, -1, "ati-vga"));
- qdev_prop_set_uint32(dev, "vgamem_mb", 16);
- qdev_prop_set_uint16(dev, "x-device-id", 0x5159);
- qdev_init_nofail(dev);
+ if (vga_interface_type != VGA_NONE) {
+ dev = DEVICE(pci_create(pci_bus, -1, "ati-vga"));
+ qdev_prop_set_uint32(dev, "vgamem_mb", 16);
+ qdev_prop_set_uint16(dev, "x-device-id", 0x5159);
+ qdev_init_nofail(dev);
+ }
/* Populate SPD eeprom data */
spd_data = spd_data_generate(DDR, ram_size, &err);
--
2.20.1
> From: Paolo Bonzini <pbonzini@redhat.com> > Cc: philmd@redhat.com; BALATON Zoltan; Aleksandar Markovic; Aleksandar Rikalo; Aurelien Jarno > Subject: [PATCH] mips-fulong2e: obey -vga none > > Do not create an ATI VGA if "-vga none" was passed on the command line. > > Cc: BALATON Zoltan <balaton@eik.bme.hu> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- This looks like a very good point to me. I am going to wait for comments of others. Many thanks, Paolo! Aleksandar P.S. Balaton Zoltan, what is your first, and what is your last name? I know "Zoltan" can be both. > hw/mips/mips_fulong2e.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/hw/mips/mips_fulong2e.c b/hw/mips/mips_fulong2e.c > index 9d7480ed31..05a5a823a1 100644 > --- a/hw/mips/mips_fulong2e.c > +++ b/hw/mips/mips_fulong2e.c > @@ -349,10 +349,12 @@ static void mips_fulong2e_init(MachineState *machine) > &smbus, &isa_bus); > > /* GPU */ > - dev = DEVICE(pci_create(pci_bus, -1, "ati-vga")); > - qdev_prop_set_uint32(dev, "vgamem_mb", 16); > - qdev_prop_set_uint16(dev, "x-device-id", 0x5159); > - qdev_init_nofail(dev); > + if (vga_interface_type != VGA_NONE) { > + dev = DEVICE(pci_create(pci_bus, -1, "ati-vga")); > + qdev_prop_set_uint32(dev, "vgamem_mb", 16); > + qdev_prop_set_uint16(dev, "x-device-id", 0x5159); > + qdev_init_nofail(dev); > + } > > /* Populate SPD eeprom data */ > spd_data = spd_data_generate(DDR, ram_size, &err); > -- > 2.20.1 >
On Tue, 19 Mar 2019, Paolo Bonzini wrote: > Do not create an ATI VGA if "-vga none" was passed on the command line. > > Cc: BALATON Zoltan <balaton@eik.bme.hu> Thanks, I did not know about this variable. Although the real hardware has the GPU soldered on the mainboard it makes sense to allow it to be disabled in QEMU especially at this stage when Linux kernel has some problem with it so this is a good idea. Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> When changing it you could also replace the -1 in pci_create with PCI_DEVFN(FULONG2E_ATI_SLOT, 0) to match the address the board has or should that be a separate patch? Regards, BALATON Zoltan > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > hw/mips/mips_fulong2e.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/hw/mips/mips_fulong2e.c b/hw/mips/mips_fulong2e.c > index 9d7480ed31..05a5a823a1 100644 > --- a/hw/mips/mips_fulong2e.c > +++ b/hw/mips/mips_fulong2e.c > @@ -349,10 +349,12 @@ static void mips_fulong2e_init(MachineState *machine) > &smbus, &isa_bus); > > /* GPU */ > - dev = DEVICE(pci_create(pci_bus, -1, "ati-vga")); > - qdev_prop_set_uint32(dev, "vgamem_mb", 16); > - qdev_prop_set_uint16(dev, "x-device-id", 0x5159); > - qdev_init_nofail(dev); > + if (vga_interface_type != VGA_NONE) { > + dev = DEVICE(pci_create(pci_bus, -1, "ati-vga")); > + qdev_prop_set_uint32(dev, "vgamem_mb", 16); > + qdev_prop_set_uint16(dev, "x-device-id", 0x5159); > + qdev_init_nofail(dev); > + } > > /* Populate SPD eeprom data */ > spd_data = spd_data_generate(DDR, ram_size, &err); >
BALATON Zoltan <balaton@eik.bme.hu> writes: > On Tue, 19 Mar 2019, Paolo Bonzini wrote: >> Do not create an ATI VGA if "-vga none" was passed on the command line. >> >> Cc: BALATON Zoltan <balaton@eik.bme.hu> > > Thanks, I did not know about this variable. Although the real hardware > has the GPU soldered on the mainboard it makes sense to allow it to be > disabled in QEMU especially at this stage when Linux kernel has some > problem with it so this is a good idea. I'm not sure. For better or worse, we have a whole bunch of global variables (manipulated with command line options) our board code may elect to honor. When a command line option ends up in a global variable the board doesn't honor, we sometimes warn the user his option is being ignored, and we sometimes ignore it silently. But that's not what I'd like to discuss today. My question today is what a virtual board should emulate, and what -nodefaults should mean. The most straightforward case is emulating a single physical board, so that we emulate exactly what's on the board, no more, no less. Anything that can be plugged into the board we model as pluggable device you add with -device. We can still have convenience options for adding such pluggable devices in a simpler way. We can even plug some by default. -nodefaults suppresses that, i.e. it gives you exactly the physical board with nothing plugged in. Things get a bit more interesting when we're emulating a family of physical boards. Say there's a bare-bones version, and another with more goodies soldered on. While we can model the two as distinct machine types, modelling as a single machine type with options (machine properties or the global variables) may be more convenient. That's okay. Note that -nodefault still gives you a faithful emulation of a physical board: the bare-bones one. Things get more interesting still when we're emulating a somewhat fuzzy idea of a zoo of physical boards, like x86 PC. I think the difference to the previous case is mostly ambiguity that comes out of the fuzziness. Here, -nodefault gives you an emulation of a physical board that could plausibly exist. Now let's circle back to this patch. mips-fulong2e emulates a physical board that has ATI VGA soldered on. After this patch, -nodefaults gives you an emulation of something that doesn't exist. Right now, that virtual frankenboard happens to work better than the more faithful emulation that has the VGA, but that's just bugs. Working around bugs is certainly relevant, just not for guiding us on basic design issues. Mind, I'm not demanding mips-fulong2e should continue to ignore -vga; that's for its maintainer to decide. I don't demand, I ask: what should a virtual board emulate? What should -nodefaults do? [...]
Le mer. 20 mars 2019 07:13, Markus Armbruster <armbru@redhat.com> a écrit : > BALATON Zoltan <balaton@eik.bme.hu> writes: > > > On Tue, 19 Mar 2019, Paolo Bonzini wrote: > >> Do not create an ATI VGA if "-vga none" was passed on the command line. > >> > >> Cc: BALATON Zoltan <balaton@eik.bme.hu> > > > > Thanks, I did not know about this variable. Although the real hardware > > has the GPU soldered on the mainboard it makes sense to allow it to be > > disabled in QEMU especially at this stage when Linux kernel has some > > problem with it so this is a good idea. > > I'm not sure. > > For better or worse, we have a whole bunch of global variables > (manipulated with command line options) our board code may elect to > honor. > > When a command line option ends up in a global variable the board > doesn't honor, we sometimes warn the user his option is being ignored, > and we sometimes ignore it silently. But that's not what I'd like to > discuss today. > > My question today is what a virtual board should emulate, and what > -nodefaults should mean. > > The most straightforward case is emulating a single physical board, so > that we emulate exactly what's on the board, no more, no less. Anything > that can be plugged into the board we model as pluggable device you add > with -device. > Yes. > We can still have convenience options for adding such pluggable devices > in a simpler way. > > We can even plug some by default. -nodefaults suppresses that, i.e. it > gives you exactly the physical board with nothing plugged in. Ideally. > Things get a bit more interesting when we're emulating a family of > physical boards. Say there's a bare-bones version, and another with > more goodies soldered on. While we can model the two as distinct > machine types, modelling as a single machine type with options (machine > properties or the global variables) may be more convenient. That's > okay. > > Note that -nodefault still gives you a faithful emulation of a physical > board: the bare-bones one. > > Things get more interesting still when we're emulating a somewhat fuzzy > idea of a zoo of physical boards, like x86 PC. I think the difference > to the previous case is mostly ambiguity that comes out of the > fuzziness. > > Here, -nodefault gives you an emulation of a physical board that could > plausibly exist. > > Now let's circle back to this patch. mips-fulong2e emulates a physical > board that has ATI VGA soldered on. After this patch, -nodefaults gives > you an emulation of something that doesn't exist. Right now, that > virtual frankenboard happens to work better than the more faithful > emulation that has the VGA, but that's just bugs. Working around bugs > is certainly relevant, just not for guiding us on basic design issues. > -display/-vga options suffers same clarity problems than -net. Is it a card device or a cable linking to a network? Here is it a card device or a cable connecting a monitor display? When cards plugged on bus via extractible slots, they are optional. If no slot (soldered) or no bus (mmio) they aren't optional. Display monitors are optional. > Mind, I'm not demanding mips-fulong2e should continue to ignore -vga; > that's for its maintainer to decide. I don't demand, I ask: what should > a virtual board emulate? What should -nodefaults do? > IMHO -nodefaults contains soldered/mmio chipsets. Whether you plug a display or not is a different story. > [...] > >
On 20/03/19 11:03, Philippe Mathieu-Daudé wrote: > > > -display/-vga options suffers same clarity problems than -net. Is it a > card device or a cable linking to a network? Here is it a card device or > a cable connecting a monitor display? -display is a cable, -vga is a card ("-nic none" is a card, "-nic anythingelse" is a card+cable; "-net nic" is a card, "-net anythingelse" is a cable). > Mind, I'm not demanding mips-fulong2e should continue to ignore -vga; > that's for its maintainer to decide. I don't demand, I ask: what should > a virtual board emulate? What should -nodefaults do? > > IMHO -nodefaults contains soldered/mmio chipsets. > Whether you plug a display or not is a different story. In principle you could also cut the copper tracks that connect the card to the PCI bus... Paolo
Hi Paolo, On 3/20/19 11:35 AM, Paolo Bonzini wrote: > On 20/03/19 11:03, Philippe Mathieu-Daudé wrote: >> >> -display/-vga options suffers same clarity problems than -net. Is it a >> card device or a cable linking to a network? Here is it a card device or >> a cable connecting a monitor display? > > -display is a cable, -vga is a card ("-nic none" is a card, "-nic > anythingelse" is a card+cable; "-net nic" is a card, "-net anythingelse" > is a cable). > >> Mind, I'm not demanding mips-fulong2e should continue to ignore -vga; >> that's for its maintainer to decide. I don't demand, I ask: what should >> a virtual board emulate? What should -nodefaults do? >> >> IMHO -nodefaults contains soldered/mmio chipsets. >> Whether you plug a display or not is a different story. > > In principle you could also cut the copper tracks that connect the card > to the PCI bus... But then you have a crippled machine... We are not trying to model that. I went back to continue a Fuloong Avocado test I started a year ago, and it was failing. I remember I had something working, so I bisected and reached this commit... 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 is the first bad commit commit 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Tue Mar 19 15:37:19 2019 +0100 mips-fulong2e: obey -vga none Do not create an ATI VGA if "-vga none" was passed on the command line. Booting PMON 1.1.2: console: PMON2000 MIPS Initializing. Standby... console: ERRORPC=00000000 CONFIG=00030932 console: PRID=00006302 console: DIMM read console: 00000080 console: read memory type console: read number of rows console: read memory size per side console: read blocks per ddrram console: read number of sides console: read width console: DIMM SIZE=10000000 console: sdcfg=3d5043df console: msize=10000000 console: Init SDRAM Done! console: Sizing caches... console: Init caches... console: godson2 caches found console: Init caches done, cfg = 00030932 console: Copy PMON to execute location... console: start = 0x85000000 console: s0 = 0x3ac00000 console: a5000000 console: a5010000 console: a5020000 console: a5030000 console: a5040000 console: copy text section done. console: Copy PMON to execute location done. console: sp=84ffc000Uncompressing Bios........................OK,Booting Bios console: FREQ console: FREI console: DONE console: TTYI console: TTYD console: ENVI console: MAPV console: Mfg 0, Id 60 console: STDV console: 80100000: heap is already above this point console: SBDD console: 686I console: 0x3f8=ff console: PPCIH console: PCI bus 0 slot 5/0: reg 0x10 = 0x0 console: PCI bus 0 slot 5/0: reg 0x14 = 0x0 console: PCI bus 0 slot 5/0: reg 0x18 = 0x0 console: PCI bus 0 slot 5/0: reg 0x1c = 0x0 console: PCI bus 0 slot 5/0: reg 0x20 = 0x0 console: PCI bus 0 slot 5/0: reg 0x24 = 0x0 console: PCI bus 0 slot 5/1: reg 0x10 = 0xfffffff9 console: PCI bus 0 slot 5/1: reg 0x14 = 0xfffffffd console: PCI bus 0 slot 5/1: reg 0x18 = 0xfffffff9 console: PCI bus 0 slot 5/1: reg 0x1c = 0xfffffffd console: PCI bus 0 slot 5/1: reg 0x20 = 0xfffffff1 console: PCI bus 0 slot 5/1: reg 0x24 = 0x0 console: PCI bus 0 slot 5/2: reg 0x10 = 0x0 console: PCI bus 0 slot 5/2: reg 0x14 = 0x0 console: PCI bus 0 slot 5/2: reg 0x18 = 0x0 console: PCI bus 0 slot 5/2: reg 0x1c = 0x0 console: PCI bus 0 slot 5/2: reg 0x20 = 0xffffffe1 console: PCI bus 0 slot 5/2: reg 0x24 = 0x0 console: PCI bus 0 slot 5/3: reg 0x10 = 0x0 console: PCI bus 0 slot 5/3: reg 0x14 = 0x0 console: PCI bus 0 slot 5/3: reg 0x18 = 0x0 console: PCI bus 0 slot 5/3: reg 0x1c = 0x0 console: PCI bus 0 slot 5/3: reg 0x20 = 0xffffffe1 console: PCI bus 0 slot 5/3: reg 0x24 = 0x0 console: PCI bus 0 slot 5/4: reg 0x10 = 0x0 console: PCI bus 0 slot 5/4: reg 0x14 = 0x0 console: PCI bus 0 slot 5/4: reg 0x18 = 0x0 console: PCI bus 0 slot 5/4: reg 0x1c = 0x0 console: PCI bus 0 slot 5/4: reg 0x20 = 0x0 console: PCI bus 0 slot 5/4: reg 0x24 = 0x0 console: PCI bus 0 slot 5/5: reg 0x10 = 0x0 console: PCI bus 0 slot 5/5: reg 0x14 = 0x0 console: PCI bus 0 slot 5/5: reg 0x18 = 0x0 console: PCI bus 0 slot 5/5: reg 0x1c = 0x0 console: PCI bus 0 slot 5/5: reg 0x20 = 0x0 console: PCI bus 0 slot 5/5: reg 0x24 = 0x0 console: PCI bus 0 slot 5/6: reg 0x10 = 0x0 console: PCI bus 0 slot 5/6: reg 0x14 = 0x0 console: PCI bus 0 slot 5/6: reg 0x18 = 0x0 console: PCI bus 0 slot 5/6: reg 0x1c = 0x0 console: PCI bus 0 slot 5/6: reg 0x20 = 0x0 console: PCI bus 0 slot 5/6: reg 0x24 = 0x0 console: PCIS console: PCIR console: PCIW console: NETI console: RTCL console: PCID console: VGAI console: Default MODE_ID 2 console: starting radeon init... ^ Current QEMU is stuck here. Before it would continue: console: iobase=bfd0a100,mmbase=b5050000 console: mc_status=5 console: mc_status=5 console: mc_status=5 console: mc_status=5 console: ppll_div_3 = 301f4 console: Wrote: 0x00000043 0x000301f4 0x00000000 (0x00000000) console: Wrote: rd=67, fd=500, pd=3 console: VCLK_ECP_CNTL = 000000C3 console: radeon init done console: FRBI console: cfb_console init,fb=b4000000 console: Video: Drawing the logo ... console: CONSOLE_SIZE 450560HSTI ... Since: 1/ the Radeon chip is soldered on the motherboard, 2/ the default BIOS expects the Radeon chip to be unconditionally present, I insist this patch is incorrect for the particular case of the Fuloong2e board. I plan to revert it when I post the test. BTW I'm not using --nodefault, I'm running default ./configure: qemu-system-mips64el -M fulong2e -bios pmon_2e.bin \ -display none -vga none -serial stdio Regards, Phil.
Hi, > 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 is the first bad commit > commit 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 > Author: Paolo Bonzini <pbonzini@redhat.com> > Date: Tue Mar 19 15:37:19 2019 +0100 > > mips-fulong2e: obey -vga none > > Do not create an ATI VGA if "-vga none" was passed on the command line. > 1/ the Radeon chip is soldered on the motherboard, > > 2/ the default BIOS expects the Radeon chip to be > unconditionally present, > > I insist this patch is incorrect for the particular case of the Fuloong2e > board. I plan to revert it when I post the test. Yep. IMHO devices which you can't unplug on the physical board should be present even with "qemu -nodefaults". cheers, Gerd
7:45 AM Pon, 06.01.2020. Gerd Hoffmann <kraxel@redhat.com> је написао/ла: > > Hi, > > > 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 is the first bad commit > > commit 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 > > Author: Paolo Bonzini <pbonzini@redhat.com> > > Date: Tue Mar 19 15:37:19 2019 +0100 > > > > mips-fulong2e: obey -vga none > > > > Do not create an ATI VGA if "-vga none" was passed on the command line. > > > 1/ the Radeon chip is soldered on the motherboard, > > > > 2/ the default BIOS expects the Radeon chip to be > > unconditionally present, > > > > I insist this patch is incorrect for the particular case of the Fuloong2e > > board. I plan to revert it when I post the test. > > Yep. IMHO devices which you can't unplug on the physical board should > be present even with "qemu -nodefaults". > I have to agree with Philippe's approach. That is not to say that Zoltan's efforts are not appreciated. Just that the patch in question that broke Foolong scenario didn't fit quite well, however some other its reincarnation may have better destiny. Sincerely, Aleksandar > cheers, > Gerd > >
8:42 PM Pet, 10.01.2020. Aleksandar Markovic <aleksandar.m.mail@gmail.com> је написао/ла: > > 7:45 AM Pon, 06.01.2020. Gerd Hoffmann <kraxel@redhat.com> је написао/ла: > > > > Hi, > > > > > 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 is the first bad commit > > > commit 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 > > > Author: Paolo Bonzini <pbonzini@redhat.com> > > > Date: Tue Mar 19 15:37:19 2019 +0100 > > > > > > mips-fulong2e: obey -vga none > > > > > > Do not create an ATI VGA if "-vga none" was passed on the command line. > > > > > 1/ the Radeon chip is soldered on the motherboard, > > > > > > 2/ the default BIOS expects the Radeon chip to be > > > unconditionally present, > > > > > > I insist this patch is incorrect for the particular case of the Fuloong2e > > > board. I plan to revert it when I post the test. > > > > Yep. IMHO devices which you can't unplug on the physical board should > > be present even with "qemu -nodefaults". > > > > I have to agree with Philippe's approach. That is not to say that Zoltan's efforts are not appreciated. I meant to say also Paolo's. But, I didn't mean to fingerpoint. It is quite normal that from time to time, a well-intended change may actually produce unexpected breaking. All is well, no bad feelings at all. Yours, Aleksandar Just that the patch in question that broke Foolong scenario didn't fit quite well, however some other its reincarnation may have better destiny. > > Sincerely, > Aleksandar > > > cheers, > > Gerd > > > >
On 04/01/20 22:16, Philippe Mathieu-Daudé wrote: > 1/ the Radeon chip is soldered on the motherboard, > > 2/ the default BIOS expects the Radeon chip to be > unconditionally present, > > I insist this patch is incorrect for the particular case of the > Fuloong2e board. I plan to revert it when I post the test. > > BTW I'm not using --nodefault, I'm running default ./configure: > > qemu-system-mips64el -M fulong2e -bios pmon_2e.bin \ > -display none -vga none -serial stdio But if you're not specifying -nodefaults, why are you specifying a configuration that your BIOS does not support? You should just remove -vga none and leave in -display none. Paolo
On 1/18/20 9:46 PM, Paolo Bonzini wrote: > On 04/01/20 22:16, Philippe Mathieu-Daudé wrote: >> 1/ the Radeon chip is soldered on the motherboard, >> >> 2/ the default BIOS expects the Radeon chip to be >> unconditionally present, >> >> I insist this patch is incorrect for the particular case of the >> Fuloong2e board. I plan to revert it when I post the test. >> >> BTW I'm not using --nodefault, I'm running default ./configure: >> >> qemu-system-mips64el -M fulong2e -bios pmon_2e.bin \ >> -display none -vga none -serial stdio > > But if you're not specifying -nodefaults, why are you specifying a > configuration that your BIOS does not support? You should just remove > -vga none and leave in -display none. OK, with this information I searched what enforcing -vga none, with: $ git grep -- -vga.*none python/ python/qemu/machine.py:232: args = ['-display', 'none', '-vga', 'none'] Context: 61 class QEMUMachine(object): ... 230 231 def _base_args(self): 232 args = ['-display', 'none', '-vga', 'none'] ... 290 def launch(self): 301 try: 302 self._launch() ... 314 def _launch(self): 315 """ 316 Launch the VM and establish a QMP connection 317 """ 318 devnull = open(os.path.devnull, 'rb') 319 self._pre_launch() 320 self._qemu_full_args = (self._wrapper + [self._binary] + 321 self._base_args() + self._args) Except the refactors moving this code, the original commit is: $ git show 0fd05e8dd1e commit 0fd05e8dd1ee7ae143fba3d6bcc6abe3fbeaeb34 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Wed Jun 6 16:23:27 2012 +0200 qemu-iotests: start vms in qtest mode This way, they will not execute any VM code at all. However, right now the cancellation test is "relying" on being slowed down by TCG executing BIOS code. So, change the timeouts. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py index e27b40e289..e05b1d640b 100644 --- a/tests/qemu-iotests/iotests.py +++ b/tests/qemu-iotests/iotests.py @@ -54,7 +54,9 @@ class VM(object): self._qemu_log_path = os.path.join(test_dir, 'qemu-log.%d' % os.getpid()) self._args = qemu_args + ['-chardev', 'socket,id=mon,path=' + self._monitor_path, - '-mon', 'chardev=mon,mode=control', '-nographic'] + '-mon', 'chardev=mon,mode=control', + '-qtest', 'stdio', '-machine', 'accel=qtest', + '-display', 'none', '-vga', 'none'] self._num_drives = 0 def add_drive(self, path, opts=''): diff --git a/tests/qemu-iotests/030 b/tests/qemu-iotests/030 index 4ab7d62961..cc671dd7aa 100755 --- a/tests/qemu-iotests/030 +++ b/tests/qemu-iotests/030 @@ -147,7 +147,7 @@ class TestStreamStop(ImageStreamingTestCase): result = self.vm.qmp('block-stream', device='drive0') self.assert_qmp(result, 'return', {}) - time.sleep(1) + time.sleep(0.1) events = self.vm.get_qmp_events(wait=False) self.assertEqual(events, [], 'unexpected QMP event: %s' % events) So IIUC we need to rework a bit the defaults of QEMUMachine::base_args.
Paolo Bonzini <pbonzini@redhat.com> writes: > On 04/01/20 22:16, Philippe Mathieu-Daudé wrote: >> 1/ the Radeon chip is soldered on the motherboard, >> >> 2/ the default BIOS expects the Radeon chip to be >> unconditionally present, >> >> I insist this patch is incorrect for the particular case of the >> Fuloong2e board. I plan to revert it when I post the test. >> >> BTW I'm not using --nodefault, I'm running default ./configure: >> >> qemu-system-mips64el -M fulong2e -bios pmon_2e.bin \ >> -display none -vga none -serial stdio > > But if you're not specifying -nodefaults, why are you specifying a > configuration that your BIOS does not support? You should just remove > -vga none and leave in -display none. Is there any use for -vga none with this machine? If no, then rejecting it cleanly would be nicer than having the machine hang.
On Tue, 21 Jan 2020, Markus Armbruster wrote: > Paolo Bonzini <pbonzini@redhat.com> writes: > >> On 04/01/20 22:16, Philippe Mathieu-Daudé wrote: >>> 1/ the Radeon chip is soldered on the motherboard, >>> >>> 2/ the default BIOS expects the Radeon chip to be >>> unconditionally present, >>> >>> I insist this patch is incorrect for the particular case of the >>> Fuloong2e board. I plan to revert it when I post the test. >>> >>> BTW I'm not using --nodefault, I'm running default ./configure: >>> >>> qemu-system-mips64el -M fulong2e -bios pmon_2e.bin \ >>> -display none -vga none -serial stdio >> >> But if you're not specifying -nodefaults, why are you specifying a >> configuration that your BIOS does not support? You should just remove >> -vga none and leave in -display none. > > Is there any use for -vga none with this machine? If no, then rejecting > it cleanly would be nicer than having the machine hang. https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg00330.html Regards, BALATON Zoltan
On Sat, 4 Jan 2020, Philippe Mathieu-Daudé wrote: > I insist this patch is incorrect for the particular case of the Fuloong2e > board. I plan to revert it when I post the test. I can only repeat my comment from when it last came up: On Wed, 20 Mar 2019, BALATON Zoltan wrote: > Thanks, I did not know about this variable. Although the real hardware > has the GPU soldered on the mainboard it makes sense to allow it to be > disabled in QEMU especially at this stage when Linux kernel has some > problem with it so this is a good idea. I think the option is useful to boot Linux now until we improve rv100 emulation enough to work with the Linux DRM driver so either way you'll have a problem: with -vga none not disabling soldered chip you can't boot normal Linux CDs without patching them, with -vga none obeyed you can't use PMON. But since PMON is not bundled in QEMU (we don't have the source of the actual board firmware, only a binary) it may be less of a problem than Linux install CDs not working. After install you could change Linux to use radeon framebuffer driver which probably works better. (Although I'm not sure if anyone actually tried to do that.) But I don't really mind either way, go with what you prefer. I only care about the chip emulations used by this board not going away as I plan to use them for pegasos2 emulation but not the fulong board itself apart from using it for cross checking changes. I know about one problem with the via-ide part that I could reproduce with both: https://osdn.net/projects/qmiga/ticket/38949 but I'm still not sure it's not missing irq emulation in my Marvel Discovery II emulation that's causing problem on pegasos2. > Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> > > When changing it you could also replace the -1 in pci_create with > PCI_DEVFN(FULONG2E_ATI_SLOT, 0) to match the address the board has or > should that be a separate patch? Looks like this above comment was not considered last time, maybe if you change it now this could be fixed as well. Regards, BALATON Zoltan
On Wed, 20 Mar 2019, Markus Armbruster wrote: > For better or worse, we have a whole bunch of global variables > (manipulated with command line options) our board code may elect to > honor. Are they documented somewhere or gathered at the same place or just scattered around in source? I may not know about them. But that's not important, as this is about -nodefaults now. > My question today is what a virtual board should emulate, and what > -nodefaults should mean. This is philosophycal not related to the fulong2e patch but I understood it as remove devices that are added by default but not needed for a minimal emulation of the machine. The help text of this option does not mention anything about relation to real hardware so it's free to define its defaults and minimal settings. > The most straightforward case is emulating a single physical board, so > that we emulate exactly what's on the board, no more, no less. Anything > that can be plugged into the board we model as pluggable device you add > with -device. > > We can still have convenience options for adding such pluggable devices > in a simpler way. > > We can even plug some by default. -nodefaults suppresses that, i.e. it > gives you exactly the physical board with nothing plugged in. This might work if we have a physical board to model but sometimes we don't (like mac99 or virt machines). Also it's often more useful to emulate a machine with its usual connected peripherals that are needed for using it conveniently so that suggests -nodefaults would be a minimal config that's still useful (e.g. with keyboard, display) but not with other optional components that are not needed to use it. (You can turn on a PC with just CPU and memory but probably can't do much useful with it other than hear it beep. Although you may try to get something working over serial if your firmware supports that or can preload a kernel in RAM in QEMU so truly minimal config might be useful but should that be another option say, -minimal or is that -nodefaults?) > Now let's circle back to this patch. mips-fulong2e emulates a physical > board that has ATI VGA soldered on. After this patch, -nodefaults gives > you an emulation of something that doesn't exist. Right now, that > virtual frankenboard happens to work better than the more faithful > emulation that has the VGA, but that's just bugs. Working around bugs > is certainly relevant, just not for guiding us on basic design issues. > > Mind, I'm not demanding mips-fulong2e should continue to ignore -vga; > that's for its maintainer to decide. I don't demand, I ask: what should > a virtual board emulate? What should -nodefaults do? Ideally the board should emulate all its components faithfully but often this is not done because of their complexity (and may not be needed as some obscure features are probably not used or can be substituted with something else we already have like another network, display or disk controller). It's still useful to have a board without all its components as guest OS may be able to work with those (especially paravirtualised Linux) so some boards in QEMU don't emulate real hardware just something that can run certain guests or when it models real hardware it may not be fully emulating every detail of it. Since this breaks your assumed relation to real hardware, the -nodefaults option also does not have such relation I think. Regards, BALATON Zoltan
BALATON Zoltan <balaton@eik.bme.hu> writes: > On Tue, 19 Mar 2019, Paolo Bonzini wrote: >> Do not create an ATI VGA if "-vga none" was passed on the command line. >> >> Cc: BALATON Zoltan <balaton@eik.bme.hu> > > Thanks, I did not know about this variable. Although the real hardware > has the GPU soldered on the mainboard it makes sense to allow it to be > disabled in QEMU especially at this stage when Linux kernel has some > problem with it so this is a good idea. > > Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> > > When changing it you could also replace the -1 in pci_create with > PCI_DEVFN(FULONG2E_ATI_SLOT, 0) to match the address the board has or > should that be a separate patch? Replacing these -1 in board code is generally a good idea. I'd make it a separate patch.
Do not create a TCX if "-vga none" was passed on the command line.
Remove some dead code along the way to avoid big reindentation.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
hw/sparc/sun4m.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/sparc/sun4m.c b/hw/sparc/sun4m.c
index ca1e3825d5..07d126aea8 100644
--- a/hw/sparc/sun4m.c
+++ b/hw/sparc/sun4m.c
@@ -850,7 +850,6 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef,
uint32_t initrd_size;
DriveInfo *fd[MAX_FD];
FWCfgState *fw_cfg;
- unsigned int num_vsimms;
DeviceState *dev;
SysBusDevice *s;
@@ -909,8 +908,7 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef,
error_report("Unsupported depth: %d", graphic_depth);
exit (1);
}
- num_vsimms = 0;
- if (num_vsimms == 0) {
+ if (vga_interface_type != VGA_NONE) {
if (vga_interface_type == VGA_CG3) {
if (graphic_depth != 8) {
error_report("Unsupported depth: %d", graphic_depth);
@@ -945,7 +943,7 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef,
}
}
- for (i = num_vsimms; i < MAX_VSIMMS; i++) {
+ for (i = 0; i < MAX_VSIMMS; i++) {
/* vsimm registers probed by OBP */
if (hwdef->vsimm[i].reg_base) {
empty_slot_init(hwdef->vsimm[i].reg_base, 0x2000);
--
2.20.1
On 19/03/2019 14:40, Paolo Bonzini wrote: > Do not create a TCX if "-vga none" was passed on the command line. > Remove some dead code along the way to avoid big reindentation. > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > hw/sparc/sun4m.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/hw/sparc/sun4m.c b/hw/sparc/sun4m.c > index ca1e3825d5..07d126aea8 100644 > --- a/hw/sparc/sun4m.c > +++ b/hw/sparc/sun4m.c > @@ -850,7 +850,6 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef, > uint32_t initrd_size; > DriveInfo *fd[MAX_FD]; > FWCfgState *fw_cfg; > - unsigned int num_vsimms; > DeviceState *dev; > SysBusDevice *s; > > @@ -909,8 +908,7 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef, > error_report("Unsupported depth: %d", graphic_depth); > exit (1); > } > - num_vsimms = 0; > - if (num_vsimms == 0) { > + if (vga_interface_type != VGA_NONE) { > if (vga_interface_type == VGA_CG3) { > if (graphic_depth != 8) { > error_report("Unsupported depth: %d", graphic_depth); > @@ -945,7 +943,7 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef, > } > } > > - for (i = num_vsimms; i < MAX_VSIMMS; i++) { > + for (i = 0; i < MAX_VSIMMS; i++) { > /* vsimm registers probed by OBP */ > if (hwdef->vsimm[i].reg_base) { > empty_slot_init(hwdef->vsimm[i].reg_base, 0x2000); > Looks sensible to me - I've always wondered why the num_vsimms code was written like this, but I can't see that this will change any existing behaviour. Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> ATB, Mark.
Hi Paolo, On 3/19/19 3:40 PM, Paolo Bonzini wrote: > Do not create a TCX if "-vga none" was passed on the command line. > Remove some dead code along the way to avoid big reindentation. Can you add: This fixes when configuring with --without-default-devices: $ sparc-softmmu/qemu-system-sparc qemu-system-sparc: Unknown device 'SUNW,tcx' for default sysbus Aborted (core dumped) (gdb) bt #1 0x00007fc78d17d895 in __GI_abort () at abort.c:79 #2 0x0000560beaf637f3 in qdev_create (bus=bus@entry=0x0, name=name@entry=0x560beb1be36b "SUNW,tcx") at hw/core/qdev.c:131 #3 0x0000560beaf1392d in tcx_init (vram_size=1048576, width=1024, height=768, depth=8, irq=0x560bed1a0230, addr=1342177280) at hw/sparc/sun4m.c:477 #4 0x0000560beaf1392d in sun4m_hw_init (hwdef=0x560beb1be780 <sun4m_hwdefs>, machine=0x560becf65f00) at hw/sparc/sun4m.c:943 #5 0x0000560beaf6b15b in machine_run_board_init (machine=0x560becf65f00) at hw/core/machine.c:1030 #6 0x0000560beae86692 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4463 > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> > --- > hw/sparc/sun4m.c | 6 ++---- > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff --git a/hw/sparc/sun4m.c b/hw/sparc/sun4m.c > index ca1e3825d5..07d126aea8 100644 > --- a/hw/sparc/sun4m.c > +++ b/hw/sparc/sun4m.c > @@ -850,7 +850,6 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef, > uint32_t initrd_size; > DriveInfo *fd[MAX_FD]; > FWCfgState *fw_cfg; > - unsigned int num_vsimms; > DeviceState *dev; > SysBusDevice *s; > > @@ -909,8 +908,7 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef, > error_report("Unsupported depth: %d", graphic_depth); > exit (1); > } > - num_vsimms = 0; > - if (num_vsimms == 0) { > + if (vga_interface_type != VGA_NONE) { > if (vga_interface_type == VGA_CG3) { > if (graphic_depth != 8) { > error_report("Unsupported depth: %d", graphic_depth); > @@ -945,7 +943,7 @@ static void sun4m_hw_init(const struct sun4m_hwdef *hwdef, > } > } > > - for (i = num_vsimms; i < MAX_VSIMMS; i++) { > + for (i = 0; i < MAX_VSIMMS; i++) { > /* vsimm registers probed by OBP */ > if (hwdef->vsimm[i].reg_base) { > empty_slot_init(hwdef->vsimm[i].reg_base, 0x2000); >
© 2016 - 2024 Red Hat, Inc.