Re: [Xen-devel] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

[Gerd Hoffmann <kraxel@xxxxxxxxxx>]

  Hi,

> Thanks for the tip that seabios allocated pages automatically become
> e820 reserved, that simplifies things a bit.

It's common practice for all firmware.  The e820 table from qemu is just
a starting point, it is not passed on to the guest os as-is.  All
permanent allocations (acpi tables, smbios tables, seabios driver data
such as virtio rings, ...) are taken away from RAM and added to
RESERVED, and IIRC seabios also takes care to reserve the bios and
option rom regions in real mode address space.

> > Maybe we should define the interface as "guest writes 0xfc to pick
> > address, qemu takes care to place opregion there".  That gives us the
> > freedom to change the qemu implementation (either copy host opregion or
> > map the host opregion) without breaking things.
> 
> Ok, so seabios allocates two pages, writes the base address of those
> pages to 0xfc and looks to see whether the signature appears at that
> address due to qemu mapping.  It verifies the size and does a
> free/realloc if not the right size.

I think seabios first needs to reserve something big enough for a
temporary mapping, to check signature + size, otherwise the opregion
might scratch data structures beyond opregion in case it happens to be
larger than 8k.

How likely is it that the opregion size ever changes?  Should we better
be prepared to handle it?  Or would it be ok to have a ...

   if (opregion_size > 8k)
      panic();

... style sanity check?

> If the graphics signature does not
> appear, free those pages and assume no opregion support.

Yes.

> If we later
> decide to use a copy, we'd need to disable the 0xfc automagic mapping
> and probably pass the data via fw_cfg.  Sound right?

I'd have qemu copy the data on 0xfc write then, so things continue to
work without updating seabios.  So, the firmware has to allocate space,
reserve it etc.,  and programming the 0xfc register.  Qemu has to make
sure the opregion appears at the address written by the firmware, by
whatever method it prefers.

> > lpc bridge is no problem, only pci id fields are copied over and
> > unprivileged access is allowed for them.
> > 
> > Copying the gfx registers of the host bridge is a problem indeed.
> 
> I would argue that both are really a problem, libvirt wants to put QEMU
> in a container that prevents access to any host system files other than
> those explicitly allowed.  Therefore libvirt needs to grant the process
> access to the lpc sysfs config file even though it only needs user
> visible register values.

Yes, correct.  We want svirt be as strict as possible.

cheers,
  Gerd


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel