Re: [Qemu-devel] What should a virtual board emulate?
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
Re: [Qemu-devel] What should a virtual board emulate?
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 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 Signed-off-by: Kevin Wolf 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.
Re: [Qemu-devel] What should a virtual board emulate?
Paolo Bonzini 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.
Re: [Qemu-devel] What should a virtual board emulate?
On Tue, 21 Jan 2020, Markus Armbruster wrote: Paolo Bonzini 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
Re: [Qemu-devel] What should a virtual board emulate?
7:45 AM Pon, 06.01.2020. Gerd Hoffmann је написао/ла: > > Hi, > > > 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 is the first bad commit > > commit 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 > > Author: Paolo Bonzini > > 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 > >
Re: [Qemu-devel] What should a virtual board emulate?
8:42 PM Pet, 10.01.2020. Aleksandar Markovic је написао/ла: > > 7:45 AM Pon, 06.01.2020. Gerd Hoffmann је написао/ла: > > > > Hi, > > > > > 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 is the first bad commit > > > commit 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 > > > Author: Paolo Bonzini > > > 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 > > > >
Re: [Qemu-devel] What should a virtual board emulate?
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 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= CONFIG=00030932 console: PRID=6302 console: DIMM read console: 0080 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=1000 console: sdcfg=3d5043df console: msize=1000 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 = 0x8500 console: s0 = 0x3ac0 console: a500 console: a501 console: a502 console: a503 console: a504 console: copy text section done. console: Copy PMON to execute location done. console: sp=84ffc000Uncompressing BiosOK,Booting Bios console: FREQ console: FREI console: DONE console: TTYI console: TTYD console: ENVI console: MAPV console: Mfg 0, Id 60 console: STDV console: 8010: 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 = 0xfff9 console: PCI bus 0 slot 5/1: reg 0x14 = 0xfffd console: PCI bus 0 slot 5/1: reg 0x18 = 0xfff9 console: PCI bus 0 slot 5/1: reg 0x1c = 0xfffd console: PCI bus 0 slot 5/1: reg 0x20 = 0xfff1 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 = 0xffe1 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 = 0xffe1 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=b505 console: mc_status=5 console: mc_status=5 console: mc_status=5 console: mc_status=5 console: ppll_div_3 = 301f4 console: Wrote: 0x0043 0x000301f4 0x (0x) console: Wrote: rd=67, fd=500, pd=3 console: VCLK_ECP_CNTL = 00C3 console: radeon init done console: FRBI console: cfb_c
Re: [Qemu-devel] What should a virtual board emulate?
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 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
Re: [Qemu-devel] What should a virtual board emulate?
Hi, > 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 is the first bad commit > commit 78c37d88f1b8b0b3ebcc632c458f0c3779fe2951 > Author: Paolo Bonzini > 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
[Qemu-devel] What should a virtual board emulate? (was: [PATCH] mips-fulong2e: obey -vga none)
BALATON Zoltan 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 > > 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? [...]
Re: [Qemu-devel] What should a virtual board emulate? (was: [PATCH] mips-fulong2e: obey -vga none)
Le mer. 20 mars 2019 07:13, Markus Armbruster a écrit : > BALATON Zoltan 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 > > > > 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. > [...] > >
Re: [Qemu-devel] What should a virtual board emulate? (was: [PATCH] mips-fulong2e: obey -vga none)
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
Re: [Qemu-devel] What should a virtual board emulate? (was: [PATCH] mips-fulong2e: obey -vga none)
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