[Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Paolo Bonzini]

Hi Gerd,

are there any reasons why virtio-input is only compiled on Linux, and
virtio-vga is only compiled on 64-bit Intel?

Paolo

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Gerd Hoffmann]

On Sa, 2015-07-11 at 19:55 +0200, Paolo Bonzini wrote:
> Hi Gerd,
> 
> are there any reasons why virtio-input is only compiled on Linux,

Fix just sent.  Early revisions used to include the system's
linux/input.h file, which doesn't exist on non-linux machines ...

> and
> virtio-vga is only compiled on 64-bit Intel?

There is virtio-gpu-pci ...

Any specific reason why we need vga compatibility on !x86?

cheers,
  Gerd

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Paolo Bonzini]

On 13/07/2015 09:32, Gerd Hoffmann wrote:
> > and virtio-vga is only compiled on 64-bit Intel?
>
> There is virtio-gpu-pci ...
> 
> Any specific reason why we need vga compatibility on !x86?

I was actually thinking about 32-bit x86. :)  I agree that !x86 is not
necessary.

Paolo

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Gerd Hoffmann]

On Mo, 2015-07-13 at 12:15 +0200, Paolo Bonzini wrote:
> 
> On 13/07/2015 09:32, Gerd Hoffmann wrote:
> > > and virtio-vga is only compiled on 64-bit Intel?
> >
> > There is virtio-gpu-pci ...
> > 
> > Any specific reason why we need vga compatibility on !x86?
> 
> I was actually thinking about 32-bit x86. :)  I agree that !x86 is not
> necessary.

Yea, setting it for i386 makes sense indeed.  Just went out of my focus,
last time I used qemu-system-i386 was a few years back ...

Any reason why one would use qemu-system-i386 instead of
qemu-system-x86_64 btw?  I suspect a 32bit host machine is the only one?

cheers,
  Gerd

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Paolo Bonzini]

On 13/07/2015 13:45, Gerd Hoffmann wrote:
>>>> > > > and virtio-vga is only compiled on 64-bit Intel?
>>> > >
>>> > > There is virtio-gpu-pci ...
>>> > > 
>>> > > Any specific reason why we need vga compatibility on !x86?
>> > 
>> > I was actually thinking about 32-bit x86. :)  I agree that !x86 is not
>> > necessary.
> Yea, setting it for i386 makes sense indeed.  Just went out of my focus,
> last time I used qemu-system-i386 was a few years back ...
> 
> Any reason why one would use qemu-system-i386 instead of
> qemu-system-x86_64 btw?  I suspect a 32bit host machine is the only one?

Yes, I think so.

Well, for TCG there is a difference of course.  Laszlo was using
qemu-system-i386 because OVMF doesn't support our x86_64 layout for the
SMM state save area.

Paolo

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Laszlo Ersek]

On 07/13/15 13:49, Paolo Bonzini wrote:
> 
> 
> On 13/07/2015 13:45, Gerd Hoffmann wrote:
>>>>>>>> and virtio-vga is only compiled on 64-bit Intel?
>>>>>>
>>>>>> There is virtio-gpu-pci ...
>>>>>>
>>>>>> Any specific reason why we need vga compatibility on !x86?
>>>>
>>>> I was actually thinking about 32-bit x86. :)  I agree that !x86 is not
>>>> necessary.
>> Yea, setting it for i386 makes sense indeed.  Just went out of my focus,
>> last time I used qemu-system-i386 was a few years back ...
>>
>> Any reason why one would use qemu-system-i386 instead of
>> qemu-system-x86_64 btw?  I suspect a 32bit host machine is the only one?
> 
> Yes, I think so.
> 
> Well, for TCG there is a difference of course.  Laszlo was using
> qemu-system-i386 because OVMF doesn't support our x86_64 layout for the
> SMM state save area.

Right, for 64-bit processors, there's one definition from AMD and
another from Intel. They are incompatible.

qemu-system-i386, with TCG, exposes the 32-bit SMM save state area that
the 32-bit SMM drivers -- open sourced by Intel, and being ported to
OVMF by yours truly -- are compatible with.

qemu-system-x86_64, with TCG, exposes the AMD flavor of the 64-bit area.
The code open sourced by Intel thus far is absolutely incompatible with
it. (In the code there are traces of support for the Intel flavor.)

With KVM support now existing (thanks Paolo), this might not be that
important any longer. (Paolo taught me that -lm can disable long mode
under KVM with qemu-system-x86_64, determining the save state aera
layout too.)

Thanks
Laszlo

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Laszlo Ersek]

Cc'ing Alex

On 07/13/15 12:15, Paolo Bonzini wrote:
> 
> 
> On 13/07/2015 09:32, Gerd Hoffmann wrote:
>>> and virtio-vga is only compiled on 64-bit Intel?
>>
>> There is virtio-gpu-pci ...
>>
>> Any specific reason why we need vga compatibility on !x86?
> 
> I was actually thinking about 32-bit x86. :)  I agree that !x86 is not
> necessary.

I disagree :)

(This is actually my more important followup to this thread; the other
message I just couldn't resist sending.)

Gerd recently contributed virtio-vga support to OvmfPkg/QemuVideoDxe:

https://github.com/tianocore/edk2/commit/94210dc9

That support depends on vga compat. All fine.

What's probably not obvious is that I had ported
PcAtChipsetPkg/PciHostBridgeDxe to ArmVirtPkg -- which drives Alex's
generic PCIe host bridge, exposed on qemu-system-(arm|aarch64) -M virt
-- and included OvmfPkg/QemuVideoDxe in the ArmVirtQemu.dsc build too.

That means you can currently stick a -device VGA into -M virt, and it
will work. Since OvmfPkg/QemuVideoDxe recognizes virtio-vga (see edk2
94210dc9 again), and the driver is included by ArmVirtQemu.dsc, I think
it would be probably useful to build the device model for arm/aarch64
targets too.

See also QEMU commit 332261de2b (together with its parent commits).

Thanks
Laszlo

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Alexander Graf]

On 07/20/15 21:06, Laszlo Ersek wrote:
> Cc'ing Alex
>
> On 07/13/15 12:15, Paolo Bonzini wrote:
>>
>> On 13/07/2015 09:32, Gerd Hoffmann wrote:
>>>> and virtio-vga is only compiled on 64-bit Intel?
>>> There is virtio-gpu-pci ...
>>>
>>> Any specific reason why we need vga compatibility on !x86?
>> I was actually thinking about 32-bit x86. :)  I agree that !x86 is not
>> necessary.
> I disagree :)
>
> (This is actually my more important followup to this thread; the other
> message I just couldn't resist sending.)
>
> Gerd recently contributed virtio-vga support to OvmfPkg/QemuVideoDxe:
>
> https://github.com/tianocore/edk2/commit/94210dc9
>
> That support depends on vga compat. All fine.
>
> What's probably not obvious is that I had ported
> PcAtChipsetPkg/PciHostBridgeDxe to ArmVirtPkg -- which drives Alex's
> generic PCIe host bridge, exposed on qemu-system-(arm|aarch64) -M virt
> -- and included OvmfPkg/QemuVideoDxe in the ArmVirtQemu.dsc build too.
>
> That means you can currently stick a -device VGA into -M virt, and it
> will work. Since OvmfPkg/QemuVideoDxe recognizes virtio-vga (see edk2

For some definition of work, yes :). It will work perfectly fine with 
TCG, you will run into cache coherency problems with KVM because the 
guest maps MMIO regions (like the vram) as uncached while QEMU accesses 
it as cached.

> 94210dc9 again), and the driver is included by ArmVirtQemu.dsc, I think
> it would be probably useful to build the device model for arm/aarch64
> targets too.
>
> See also QEMU commit 332261de2b (together with its parent commits).

I agree. Also, as far as I understood Marc, his hope was that the fix to 
halfway working VGA emulation would be virtio-gpu.


Alex

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Laszlo Ersek]

On 07/21/15 14:08, Alexander Graf wrote:
> On 07/20/15 21:06, Laszlo Ersek wrote:
>> Cc'ing Alex
>>
>> On 07/13/15 12:15, Paolo Bonzini wrote:
>>>
>>> On 13/07/2015 09:32, Gerd Hoffmann wrote:
>>>>> and virtio-vga is only compiled on 64-bit Intel?
>>>> There is virtio-gpu-pci ...
>>>>
>>>> Any specific reason why we need vga compatibility on !x86?
>>> I was actually thinking about 32-bit x86. :)  I agree that !x86 is not
>>> necessary.
>> I disagree :)
>>
>> (This is actually my more important followup to this thread; the other
>> message I just couldn't resist sending.)
>>
>> Gerd recently contributed virtio-vga support to OvmfPkg/QemuVideoDxe:
>>
>> https://github.com/tianocore/edk2/commit/94210dc9
>>
>> That support depends on vga compat. All fine.
>>
>> What's probably not obvious is that I had ported
>> PcAtChipsetPkg/PciHostBridgeDxe to ArmVirtPkg -- which drives Alex's
>> generic PCIe host bridge, exposed on qemu-system-(arm|aarch64) -M virt
>> -- and included OvmfPkg/QemuVideoDxe in the ArmVirtQemu.dsc build too.
>>
>> That means you can currently stick a -device VGA into -M virt, and it
>> will work. Since OvmfPkg/QemuVideoDxe recognizes virtio-vga (see edk2
> 
> For some definition of work, yes :). It will work perfectly fine with
> TCG, you will run into cache coherency problems with KVM because the
> guest maps MMIO regions (like the vram) as uncached while QEMU accesses
> it as cached.

Yes, I'm aware, I just didn't want to drag that thread into this
discusson as well ;)

> 
>> 94210dc9 again), and the driver is included by ArmVirtQemu.dsc, I think
>> it would be probably useful to build the device model for arm/aarch64
>> targets too.
>>
>> See also QEMU commit 332261de2b (together with its parent commits).
> 
> I agree. Also, as far as I understood Marc, his hope was that the fix to
> halfway working VGA emulation would be virtio-gpu.

Not sure how (if!) we're going to be able to drive that from the
firmware! :)

Thanks
Laszlo

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Marc Zyngier]

On Tue, 21 Jul 2015 13:08:08 +0100
Alexander Graf <agraf@suse.de> wrote:

> On 07/20/15 21:06, Laszlo Ersek wrote:
> > Cc'ing Alex
> >
> > On 07/13/15 12:15, Paolo Bonzini wrote:
> >>
> >> On 13/07/2015 09:32, Gerd Hoffmann wrote:
> >>>> and virtio-vga is only compiled on 64-bit Intel?
> >>> There is virtio-gpu-pci ...
> >>>
> >>> Any specific reason why we need vga compatibility on !x86?
> >> I was actually thinking about 32-bit x86. :)  I agree that !x86 is not
> >> necessary.
> > I disagree :)
> >
> > (This is actually my more important followup to this thread; the other
> > message I just couldn't resist sending.)
> >
> > Gerd recently contributed virtio-vga support to OvmfPkg/QemuVideoDxe:
> >
> > https://github.com/tianocore/edk2/commit/94210dc9
> >
> > That support depends on vga compat. All fine.
> >
> > What's probably not obvious is that I had ported
> > PcAtChipsetPkg/PciHostBridgeDxe to ArmVirtPkg -- which drives Alex's
> > generic PCIe host bridge, exposed on qemu-system-(arm|aarch64) -M virt
> > -- and included OvmfPkg/QemuVideoDxe in the ArmVirtQemu.dsc build too.
> >
> > That means you can currently stick a -device VGA into -M virt, and it
> > will work. Since OvmfPkg/QemuVideoDxe recognizes virtio-vga (see edk2
> 
> For some definition of work, yes :). It will work perfectly fine with 
> TCG, you will run into cache coherency problems with KVM because the 
> guest maps MMIO regions (like the vram) as uncached while QEMU accesses 
> it as cached.
> 
> > 94210dc9 again), and the driver is included by ArmVirtQemu.dsc, I think
> > it would be probably useful to build the device model for arm/aarch64
> > targets too.
> >
> > See also QEMU commit 332261de2b (together with its parent commits).
> 
> I agree. Also, as far as I understood Marc, his hope was that the fix to 
> halfway working VGA emulation would be virtio-gpu.

My hope is two-fold:

1) Adapt/fix drivers that assume certain behaviors inherited from x86.
That's mostly for legacy HW (or rather HW emulation) that people "graft"
on ARM VMs.

2) Use the fact that there is actually hardly any legacy for ARM VMs,
and embrace paravirtualized devices entirely. We do it for disks,
network interfaces. Why not display? Why not input?

Using VGA makes sense on x86 because this is a standard on that
platform. Every system has one. You can't expect the same thing on ARM
(evil persons would even say that you can't expect anything at all). So
let's take this opportunity to use the best tool for the job. Virtio
fits that bill pretty well apparently.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Gerd Hoffmann]

  Hi,

> > I agree. Also, as far as I understood Marc, his hope was that the fix to 
> > halfway working VGA emulation would be virtio-gpu.

Note we have both virtio-vga and virtio-gpu-pci.  virtio-vga has vga
compatibility built-in, otherwise the two are identical.  virtio-gpu-pci
is enabled along with all other virtio drivers, so arm + aarch64 have
that already.

> 2) Use the fact that there is actually hardly any legacy for ARM VMs,
> and embrace paravirtualized devices entirely. We do it for disks,
> network interfaces. Why not display? Why not input?

We have both now (qemu 2.4+, linux 4.1+ for input, linux 4.2+ for gpu).
Works just fine on arm (tcg tested).  aarch64 not yet (with vanilla
upstream linux kernel) due to lack of generic pci host support.

> Using VGA makes sense on x86 because this is a standard on that
> platform. Every system has one. You can't expect the same thing on ARM
> (evil persons would even say that you can't expect anything at all). So
> let's take this opportunity to use the best tool for the job. Virtio
> fits that bill pretty well apparently.

Big question is (a) whenever we need a firmware framebuffer and (b) how
to implement that best.

virtio-vga/virtio-gpu-pci in paravirt (native) mode requires the guest
explicitly request screen updates.  There is no dirty page tracking, and
guest writes to memory do *not* magically appear on the screen.  I don't
think implementing a EFI driver for that is going to fly.

virtio-vga in vga-compat mode uses a framebuffer with the usual dirty
tracking logic in pci bar 0 (simliar to stdvga).  Which is exactly the
thing causing the cache coherency issues on aarch64 if I understand
things correctly.  Programming (modesetting) works without legacy vga io
ports, you can use the mmio regs in pci bar 1 instead (applies to both
virtio-vga and stdvga btw), and QemuVideoDxe actually uses the mmio bar.

cheers,
  Gerd

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Laszlo Ersek]

On 07/25/15 11:49, Gerd Hoffmann wrote:
>   Hi,
> 
>>> I agree. Also, as far as I understood Marc, his hope was that the fix to 
>>> halfway working VGA emulation would be virtio-gpu.
> 
> Note we have both virtio-vga and virtio-gpu-pci.  virtio-vga has vga
> compatibility built-in, otherwise the two are identical.  virtio-gpu-pci
> is enabled along with all other virtio drivers, so arm + aarch64 have
> that already.
> 
>> 2) Use the fact that there is actually hardly any legacy for ARM VMs,
>> and embrace paravirtualized devices entirely. We do it for disks,
>> network interfaces. Why not display? Why not input?
> 
> We have both now (qemu 2.4+, linux 4.1+ for input, linux 4.2+ for gpu).
> Works just fine on arm (tcg tested).  aarch64 not yet (with vanilla
> upstream linux kernel) due to lack of generic pci host support.
> 
>> Using VGA makes sense on x86 because this is a standard on that
>> platform. Every system has one. You can't expect the same thing on ARM
>> (evil persons would even say that you can't expect anything at all). So
>> let's take this opportunity to use the best tool for the job. Virtio
>> fits that bill pretty well apparently.
> 
> Big question is (a) whenever we need a firmware framebuffer and (b) how
> to implement that best.
> 
> virtio-vga/virtio-gpu-pci in paravirt (native) mode requires the guest
> explicitly request screen updates.  There is no dirty page tracking, and
> guest writes to memory do *not* magically appear on the screen.  I don't
> think implementing a EFI driver for that is going to fly.

The EFI_GRAPHICS_OUTPUT_PROTOCOL structure has a function pointer member
called Blt:

  Blt -- Software abstraction to draw on the video device’s frame
         buffer.
  [...]
         Blt a rectangle of pixels on the graphics screen. Blt stands
         for BLock Transfer.

And, one of the enumeration constants that are possible for the
EFI_GRAPHICS_OUTPUT_PROTOCOL.Mode->Info->PixelFormat field is:

  PixelBltOnly -- This mode does not support a physical frame buffer.

Therefore, strictly for working before ExitBootServices(), a UEFI_DRIVER
module could be implemented that exposed a "blit-only" interface. I have
never tested if the higher level graphics stack in edk2 would work with
that; I guess it might. And, if we force all display accesses through
Blt(), then all the necessary virtio stuff could be done in there, I guess.

The problem is however runtime OS support, after ExitBootServices().
Take for example Windows 8 or Linux (without specific video drivers) on
a UEFI system. The respective boot loader or stub (launched as a UEFI
application) is smart enough to save the framebuffer characteristics for
the OS, *if* there is a physical framebuffer, and then the OS can use a
generic "efifb" driver, directly accessing the video RAM. For Windows 8
and later, this was the only way to have graphics when booting on top of
OVMF, at least until Vadim Rozenfeld completed the QXL WDDM driver.

In brief: PixelBltOnly would be *probably* okay until
ExitBootServices(), but without a physical frame buffer, UEFI operating
systems without native virtio-gpu-pci drivers could not display graphics.

(Recall Windows 7, and the VBE shim we came up with for it -- if the OS
doesn't have graphics after ExitBootServices(), either because the OS is
broken (Windows 7) or because the display is PixelBltOnly, then it can't
even be installed. You can select storage drivers mid-installation
(which runs after ExitBootServices()), but not video.)

> virtio-vga in vga-compat mode uses a framebuffer with the usual dirty
> tracking logic in pci bar 0 (simliar to stdvga).  Which is exactly the
> thing causing the cache coherency issues on aarch64 if I understand
> things correctly.

Yes. :(

> Programming (modesetting) works without legacy vga io
> ports, you can use the mmio regs in pci bar 1 instead (applies to both
> virtio-vga and stdvga btw), and QemuVideoDxe actually uses the mmio bar.

True.

But, as a side point, let me talk a bit about the outb() function in
OvmfPkg/QemuVideoDxe/Driver.c. It (very correctly for a UEFI_DRIVER
module!) uses PciIo->Io.Write() to write to IO ports.

Now, the PciIo protocol implementation is platform independent. In
practice it forwards IO space accesses to the EFI_PCI_ROOT_BRIDGE_IO
protocol. And *that* one is platform-dependent.

For x86 virtual machines, those accesses are turned into IO port
accesses. However, the EFI_PCI_ROOT_BRIDGE_IO implementation in
ArmVirtPkg/PciHostBridgeDxe/, which is built into AAVMF and runs on the
"virt" machtype, maps the IO space and the IO port accesses to a special
(fake) MMIO range of 64K "ports".

In QEMU this memory region corresponds to VIRT_PCIE_PIO, in
"hw/arm/virt.c". See create_pcie():

    hwaddr base_pio = vbi->memmap[VIRT_PCIE_PIO].base;

    ...

    /* Map IO port space */
    sysbus_mmio_map(SYS_BUS_DEVICE(dev), 2, base_pio);

This range is advertized in the DTB that QEMU exports to AAVMF, which is
how AAVMF knows how to do the translation.

I believe such an emulated IO space was necessary for most QEMU device
models in the first place (I guess quite a few of them must have a hard
IO space dependency). Now that it's there, we can drive it from AAVMF.
(Whether the IO space emulation is temporary or here to stay in QEMU, I
don't know.)

Anyhow, this wall of text is just to say: *if* QemuVideoDxe, built for
AAVMF, had to fall back to legacy VGA IO ports, for whatever reason, it
would be capable of that. The PciIo->Io.Write() accesses made in
QemuVideoDxe would be "diverted" by ArmVirtPkg/PciHostBridgeDxe to the
special MMIO range. (Are abstractions awesome or what?! :))

Thanks
Laszlo

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Peter Maydell]

On 26 July 2015 at 10:31, Laszlo Ersek <lersek@redhat.com> wrote:
> On 07/25/15 11:49, Gerd Hoffmann wrote:
>> virtio-vga in vga-compat mode uses a framebuffer with the usual dirty
>> tracking logic in pci bar 0 (simliar to stdvga).  Which is exactly the
>> thing causing the cache coherency issues on aarch64 if I understand
>> things correctly.
>
> Yes. :(

The question for cache-coherency of an emulated framebuffer with
KVM is simply "does the guest set up this region of physical address
space as Normal Cacheable memory, or does it set it up as Device
or some other non-cacheable memory attribute type?". Whether the
framebuffer is part of a PCI BAR or shared with "guest RAM" doesn't
matter for this. (Of course it may matter for the guest if the
guest makes assumptions about what kind of mapping it needs to
use for any PCI BAR.)

[NB: this is a statement about the current situation of kernel and
QEMU code and doesn't take account of any attempts we might make to
make things work better.]

>> Programming (modesetting) works without legacy vga io
>> ports, you can use the mmio regs in pci bar 1 instead (applies to both
>> virtio-vga and stdvga btw), and QemuVideoDxe actually uses the mmio bar.
>
> True.
>
> But, as a side point, let me talk a bit about the outb() function in
> OvmfPkg/QemuVideoDxe/Driver.c. It (very correctly for a UEFI_DRIVER
> module!) uses PciIo->Io.Write() to write to IO ports.
>
> Now, the PciIo protocol implementation is platform independent. In
> practice it forwards IO space accesses to the EFI_PCI_ROOT_BRIDGE_IO
> protocol. And *that* one is platform-dependent.
>
> For x86 virtual machines, those accesses are turned into IO port
> accesses. However, the EFI_PCI_ROOT_BRIDGE_IO implementation in
> ArmVirtPkg/PciHostBridgeDxe/, which is built into AAVMF and runs on the
> "virt" machtype, maps the IO space and the IO port accesses to a special
> (fake) MMIO range of 64K "ports".
>
> In QEMU this memory region corresponds to VIRT_PCIE_PIO, in
> "hw/arm/virt.c". See create_pcie():
>
>     hwaddr base_pio = vbi->memmap[VIRT_PCIE_PIO].base;
>
>     ...
>
>     /* Map IO port space */
>     sysbus_mmio_map(SYS_BUS_DEVICE(dev), 2, base_pio);

This seems to me to be confusing two things:
 (1) x86-style IO ports as accessed via inb/outb insns
 (2) PCI IO space

For the ARM boards we certainly support the latter (it's part
of the PCI spec and mapping PCI IO space to some window in
physical address space is the usual approach for CPUs which
don't have x86's special-purpose io instructions). This isn't
going to go away because you need it for dealing with PCI
devices that have IO BARs. To access registers in this window
the guest needs to program the PCI card's IO BAR to make it
appear somewhere in the window.

We don't support legacy VGO io ports, which on x86 just
always exist whether the guest programs a PCI BAR or not,
and which have fixed legacy port numbers.

thanks
-- PMM

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Peter Maydell]

On 26 July 2015 at 11:17, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 26 July 2015 at 10:31, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 07/25/15 11:49, Gerd Hoffmann wrote:
>>> virtio-vga in vga-compat mode uses a framebuffer with the usual dirty
>>> tracking logic in pci bar 0 (simliar to stdvga).  Which is exactly the
>>> thing causing the cache coherency issues on aarch64 if I understand
>>> things correctly.
>>
>> Yes. :(
>
> The question for cache-coherency of an emulated framebuffer with
> KVM is simply "does the guest set up this region of physical address
> space as Normal Cacheable memory, or does it set it up as Device
> or some other non-cacheable memory attribute type?". Whether the
> framebuffer is part of a PCI BAR or shared with "guest RAM" doesn't
> matter for this. (Of course it may matter for the guest if the
> guest makes assumptions about what kind of mapping it needs to
> use for any PCI BAR.)

...and note also that it doesn't matter for this whether the
guest expects the graphics device to automatically notice
writes via dirty-tracking or whether it explicitly says "hey
I wrote to the framebuffer" somehow -- if the guest and QEMU
disagree about whether the memory is cacheable then you are
potentially going to run into corruption problems.

-- PMM

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Laszlo Ersek]

On 07/26/15 12:17, Peter Maydell wrote:
> On 26 July 2015 at 10:31, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 07/25/15 11:49, Gerd Hoffmann wrote:
>>> virtio-vga in vga-compat mode uses a framebuffer with the usual dirty
>>> tracking logic in pci bar 0 (simliar to stdvga).  Which is exactly the
>>> thing causing the cache coherency issues on aarch64 if I understand
>>> things correctly.
>>
>> Yes. :(
> 
> The question for cache-coherency of an emulated framebuffer with
> KVM is simply "does the guest set up this region of physical address
> space as Normal Cacheable memory, or does it set it up as Device
> or some other non-cacheable memory attribute type?". Whether the
> framebuffer is part of a PCI BAR or shared with "guest RAM" doesn't
> matter for this. (Of course it may matter for the guest if the
> guest makes assumptions about what kind of mapping it needs to
> use for any PCI BAR.)
> 
> [NB: this is a statement about the current situation of kernel and
> QEMU code and doesn't take account of any attempts we might make to
> make things work better.]
> 
>>> Programming (modesetting) works without legacy vga io
>>> ports, you can use the mmio regs in pci bar 1 instead (applies to both
>>> virtio-vga and stdvga btw), and QemuVideoDxe actually uses the mmio bar.
>>
>> True.
>>
>> But, as a side point, let me talk a bit about the outb() function in
>> OvmfPkg/QemuVideoDxe/Driver.c. It (very correctly for a UEFI_DRIVER
>> module!) uses PciIo->Io.Write() to write to IO ports.
>>
>> Now, the PciIo protocol implementation is platform independent. In
>> practice it forwards IO space accesses to the EFI_PCI_ROOT_BRIDGE_IO
>> protocol. And *that* one is platform-dependent.
>>
>> For x86 virtual machines, those accesses are turned into IO port
>> accesses. However, the EFI_PCI_ROOT_BRIDGE_IO implementation in
>> ArmVirtPkg/PciHostBridgeDxe/, which is built into AAVMF and runs on the
>> "virt" machtype, maps the IO space and the IO port accesses to a special
>> (fake) MMIO range of 64K "ports".
>>
>> In QEMU this memory region corresponds to VIRT_PCIE_PIO, in
>> "hw/arm/virt.c". See create_pcie():
>>
>>     hwaddr base_pio = vbi->memmap[VIRT_PCIE_PIO].base;
>>
>>     ...
>>
>>     /* Map IO port space */
>>     sysbus_mmio_map(SYS_BUS_DEVICE(dev), 2, base_pio);
> 
> This seems to me to be confusing two things:
>  (1) x86-style IO ports as accessed via inb/outb insns
>  (2) PCI IO space
> 
> For the ARM boards we certainly support the latter (it's part
> of the PCI spec and mapping PCI IO space to some window in
> physical address space is the usual approach for CPUs which
> don't have x86's special-purpose io instructions). This isn't
> going to go away because you need it for dealing with PCI
> devices that have IO BARs. To access registers in this window
> the guest needs to program the PCI card's IO BAR to make it
> appear somewhere in the window.
> 
> We don't support legacy VGO io ports, which on x86 just
> always exist whether the guest programs a PCI BAR or not,
> and which have fixed legacy port numbers.

I was wrong to call the PCI IO space "fake", sorry about that, and
thanks for the correction. But, whatever i said about the guest
firmware, should be correct. "outb" in the QemuVideoDxe source is just a
familiar name that Jordan chose in 2011. However, it correctly calls
PciIo->Io.Write(), which on x86 (ultimately, through several layers)
results in ioport instructions, and on arm results in MMIO accesses.

I may not have understood the full theoretical background of
FDT_PCI_RANGE_IOPORT, but I think the firmware code that puts it to use
is correct.

Thanks
Laszlo

Re: [Qemu-devel] selecting VIRTIO_INPUT and VIRTIO_VGA

[Marc Zyngier]

Hi Gerd,

On 25/07/15 10:49, Gerd Hoffmann wrote:
>   Hi,
> 
>>> I agree. Also, as far as I understood Marc, his hope was that the fix to 
>>> halfway working VGA emulation would be virtio-gpu.
> 
> Note we have both virtio-vga and virtio-gpu-pci.  virtio-vga has vga
> compatibility built-in, otherwise the two are identical.  virtio-gpu-pci
> is enabled along with all other virtio drivers, so arm + aarch64 have
> that already.
> 
>> 2) Use the fact that there is actually hardly any legacy for ARM VMs,
>> and embrace paravirtualized devices entirely. We do it for disks,
>> network interfaces. Why not display? Why not input?
> 
> We have both now (qemu 2.4+, linux 4.1+ for input, linux 4.2+ for gpu).
> Works just fine on arm (tcg tested).  aarch64 not yet (with vanilla
> upstream linux kernel) due to lack of generic pci host support.
> 
>> Using VGA makes sense on x86 because this is a standard on that
>> platform. Every system has one. You can't expect the same thing on ARM
>> (evil persons would even say that you can't expect anything at all). So
>> let's take this opportunity to use the best tool for the job. Virtio
>> fits that bill pretty well apparently.
> 
> Big question is (a) whenever we need a firmware framebuffer and (b) how
> to implement that best.
> 
> virtio-vga/virtio-gpu-pci in paravirt (native) mode requires the guest
> explicitly request screen updates.  There is no dirty page tracking, and
> guest writes to memory do *not* magically appear on the screen.  I don't
> think implementing a EFI driver for that is going to fly.
> 
> virtio-vga in vga-compat mode uses a framebuffer with the usual dirty
> tracking logic in pci bar 0 (simliar to stdvga).  Which is exactly the
> thing causing the cache coherency issues on aarch64 if I understand
> things correctly. 

If this new virtio-vga driver still insists on always mapping the memory
as "non-cacheable", then it will face the same fate indeed. Which is a
bit odd, as it really *knows* this is a paravirtualized device, and that
the data will be read back from the CPU side.

The dirty tracking logic plays no part in that, AFAIK.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...