Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file

[Igor Mammedov]

On Thu, 16 Jul 2015 10:30:41 +0300
"Michael S. Tsirkin" <address@hidden> wrote:

> On Thu, Jul 16, 2015 at 08:57:36AM +0200, Igor Mammedov wrote:
> > On Wed, 15 Jul 2015 19:24:33 +0300
> > "Michael S. Tsirkin" <address@hidden> wrote:
> > 
> > > On Wed, Jul 15, 2015 at 06:01:42PM +0200, Igor Mammedov wrote:
> > > > On Wed, 15 Jul 2015 17:08:27 +0300
> > > > "Michael S. Tsirkin" <address@hidden> wrote:
> > > > 
> > > > > On Mon, Jul 13, 2015 at 04:09:37PM -0400, Gabriel L. Somlo wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > A while ago I was pondering on the options available for retrieving
> > > > > > a fw_cfg blob from the guest-side (now that we can insert fw_cfg
> > > > > > files on the host-side command line, see commit 81b2b8106).
> > > > > > 
> > > > > > So over the last couple of weekends I cooked up the sysfs kernel
> > > > > > module below, which lists all fw_cfg files
> > > > > > under /sys/firmware/fw_cfg/<filename>.
> > > > > 
> > > > > One concern here is that there will be a conflict here if fw cfg
> > > > > is used by ACPI. I don't know whether that last is a good idea
> > > > > though, so maybe not a real concern. I think Igor
> > > > > wanted to make it so.
> > > > 
> > > > I don't see any conflict here so far, it's just guest side module that
> > > > accesses fw_cfg.
> > > 
> > > If there's ACPI code that accesses fw_cfg in response to an interrupt,
> > > it'll race with fw cfg access by guest OS. On linux we might be able to
> > > block ACPI preventing it from running. We probably won't be able to do
> > > it on windows.
> > wrt vmgenid series we were talking about possibility to access fw_cfg
> > from ACPI device.init so it's unlikely that it will ever collide with
> > much later sysfs accesses.
> 
> Don't we need to get updates when it changes too?
I've thought that it's pretty static and doesn't change.

> 
> > But if ACPI will start accessing fw_cfg from
> > other methods it will race for sure.
> 
> Maybe we shouldn't poke at fw cfg in ACPI then.
Yep, maybe we shouldn't.

The last vmgenid series just maps UUID region
at fixed location (which is sufficient to build ACPI
tables at machine done time) so there isn't real need
to export address via fw_cfg.