Re: [Qemu-devel] "Using Python to investigate EFI and ACPI"

[josh]

On Thu, Sep 03, 2015 at 07:19:40PM +0200, Laszlo Ersek wrote:
> On 09/03/15 18:41, address@hidden wrote:
> > On Thu, Sep 03, 2015 at 05:53:45PM +0200, Laszlo Ersek wrote:
> >> On 09/03/15 16:50, Josh Triplett wrote:
> 
> >>> Do you virtualize those I/O ports by CPU, to make them thread-safe, or
> >>> does the last address written to 0x510 get saved system-wide, making it
> >>> unsafe for concurrent access?
> >>
> >> I think fw_cfg is not meant to be accessed by several CPUs concurrently.
> >> The protocol is stateful (selected key, offset within blob associated
> >> with selected key, etc), and "accessing CPU" is not part of that state.
> > 
> > Not that hard to fix; just keep all the state in the accessing CPU
> > rather than the system.  Current processors do that for the PCI I/O port
> > pair, to avoid race conditions.  You could easily do that for the fw_cfg
> > I/O ports.  As a bonus, you then wouldn't need to take any kind of lock
> > around accesses to that state, because the CPU owns that state.
> > 
> > (That's the easy fix; the harder fix would be creating a new race-free
> > MMIO protocol and mapping all of the data structures into memory
> > directly, which would provide a performance benefit as well.  I'd love
> > to see a general version of such a protocol for a more efficient virtio
> > filesystem, though in the simpler case of fw_cfg you can just map all of
> > the structures into memory.)
> 
> Well, first of all it should be justified why concurrent access to
> fw_cfg would be necessary / useful :) But, I'm not arguing against it
> per se; until very-very recently, the only client looking at fw_cfg has
> been the firmware (it's called "firmware config" after all), and it's
> quite natural to require that part of the firmware to be single-threaded.

As systems get larger, it may start making sense to have multi-threaded
firmware and initialization.

> Now, there's a fully independent discussion / development underway that
> might want to expose fw_cfg to the kernel too. Let's not get into that
> here, please talk to Gabriel for references :) (Cc'd).

That's another reason to want a concurrency-safe protocol. :)

> There's *yet another* development underway for speeding up fw_cfg
> transfers; please talk to Marc Marí (Cc'd) about those :)
> 
> In any case, if what you need resembles a "general virtio filesystem",
> then please just use that -- a virtio-block or virtio-scsi disk, with a
> normal filesystem on it. The protocol is industry standard and the
> performance of the QEMU (and kernel) implementation is splendid.

Not at all what I'm looking for; I'm looking for a *filesystem*, like
virtio-9p, but with significantly better performance.  I agree that
starting from fw_cfg for that is probably a bad idea; it's more that if
a high-performance virtio filesystem existed, it might also work for
fw_cfg. :)

> (For ad-hoc uses, even the "vfat" backend can be used, which practically
> implements semihosting.)

Last time I'd looked at it, that backend didn't support writing, only
reading.  You also couldn't safely change the files with the VM running.
FAT also doesn't support any semblance of POSIX semantics.

I don't think a manufactured block device is the right interface here.

> fw_cfg was always meant as a set of small bits for the firmware to
> consume. The fact that we squeeze kernel and initrd blobs through it is
> just historical abuse that is now impossible to eradicate (and must be
> sped up instead :(). Whereas other creative reasons that Gabriel could
> tell you about why the kernel could be interested in fw_cfg, are just
> that: creativity. Which might be better served by virtio too (this is
> the subject of ongoing discussion).

Sure, any replacement protocol should probably go through virtio. :)

> >> If that is the case, then this tool could become the killer ACPI tester
> >> for QEMU developers -- the hardware accesses in the AML methods
> >> generated by QEMU would actually poke QEMU devices! (Unlike the
> >> userspace "acpiexec" utility.) It would completely detach Linux guest
> >> driver development from host side / firmware development. \o/
> > 
> > That's exactly why we went with a pre-OS environment rather than an OS;
> > you don't want to undermine the OS, and you don't want your tests
> > affected by whatever the OS has done.
> 
> And, since you implemented it as part of GRUB, it is not tied to either
> OVMF or SeaBIOS (speaking in virt terms for now) -- it's flexible.

Right, exactly.  We don't have any plans to make UEFI a hard
requirement, though some future features will likely only work on UEFI
(such as our current WIP support for TCP/IP networking).

- Josh Triplett