[Qemu-devel] [PATCH] mips-fulong2e: obey -vga none

Paolo Bonzini posted 1 patch 5 years, 1 month ago
Test docker-clang@ubuntu passed
Test asan passed
Test checkpatch passed
Test docker-mingw@fedora passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20190319144013.26584-1-pbonzini@redhat.com
Maintainers: Aleksandar Rikalo <arikalo@wavecomp.com>, Aurelien Jarno <aurelien@aurel32.net>, Aleksandar Markovic <amarkovic@wavecomp.com>
hw/mips/mips_fulong2e.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
[Qemu-devel] [PATCH] mips-fulong2e: obey -vga none
Posted by Paolo Bonzini 5 years, 1 month ago
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


Re: [Qemu-devel] [PATCH] mips-fulong2e: obey -vga none
Posted by Aleksandar Markovic 5 years, 1 month ago
> 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
> 

Re: [Qemu-devel] [PATCH] mips-fulong2e: obey -vga none
Posted by BALATON Zoltan 5 years, 1 month ago
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);
>

[Qemu-devel] What should a virtual board emulate? (was: [PATCH] mips-fulong2e: obey -vga none)
Posted by Markus Armbruster 5 years, 1 month ago
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?

[...]

Re: [Qemu-devel] What should a virtual board emulate? (was: [PATCH] mips-fulong2e: obey -vga none)
Posted by Philippe Mathieu-Daudé 5 years, 1 month ago
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.


> [...]
>
>
Re: [Qemu-devel] What should a virtual board emulate? (was: [PATCH] mips-fulong2e: obey -vga none)
Posted by Paolo Bonzini 5 years, 1 month ago
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?
Posted by Philippe Mathieu-Daudé 4 years, 4 months ago
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.


Re: [Qemu-devel] What should a virtual board emulate?
Posted by Gerd Hoffmann 4 years, 4 months ago
  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


Re: [Qemu-devel] What should a virtual board emulate?
Posted by Aleksandar Markovic 4 years, 3 months ago
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
>
>
Re: [Qemu-devel] What should a virtual board emulate?
Posted by Aleksandar Markovic 4 years, 3 months ago
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
> >
> >
Re: [Qemu-devel] What should a virtual board emulate?
Posted by Paolo Bonzini 4 years, 3 months ago
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?
Posted by Philippe Mathieu-Daudé 4 years, 3 months ago
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.

Re: [Qemu-devel] What should a virtual board emulate?
Posted by Markus Armbruster 4 years, 3 months ago
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.


Re: [Qemu-devel] What should a virtual board emulate?
Posted by BALATON Zoltan 4 years, 3 months ago
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
Re: [Qemu-devel] What should a virtual board emulate?
Posted by BALATON Zoltan 4 years, 4 months ago
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
Re: [Qemu-devel] What should a virtual board emulate? (was: [PATCH] mips-fulong2e: obey -vga none)
Posted by BALATON Zoltan 5 years, 1 month ago
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

Re: [Qemu-devel] [PATCH] mips-fulong2e: obey -vga none
Posted by Markus Armbruster 5 years, 1 month ago
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.

[Qemu-devel] [PATCH] sun4m: obey -vga none
Posted by Paolo Bonzini 5 years, 1 month ago
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


Re: [Qemu-devel] [PATCH] sun4m: obey -vga none
Posted by Mark Cave-Ayland 5 years, 1 month ago
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.

Re: [Qemu-devel] [PATCH] sun4m: obey -vga none
Posted by Philippe Mathieu-Daudé 5 years, 1 month ago
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);
>