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

[Gabriel L. Somlo]

On Wed, Jul 15, 2015 at 07:24:33PM +0300, Michael S. Tsirkin 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.

Do you mean something like:

+       uint32_t acpi_lock
        mutex_lock(&fw_cfg_dev_lock);
+       acpi_ackquire_global_lock(ACPI_WAIT_FOREVER, &acpi_lock);
        outw(select, FW_CFG_PORT_CTL);
        while (pos-- > 0)
                inb(FW_CFG_PORT_DATA);
        insb(FW_CFG_PORT_DATA, buf, count);
+       acpi_release_global_lock(0, &acpi_lock);
        mutex_unlock(&fw_cfg_dev_lock);

with the expectation that ACPI would try to grab that global lock
itself before fiddling with (mm)io ?

Thanks,
--Gabriel