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" <m...@redhat.com> 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" <m...@redhat.com> 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? > 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. -- MST
