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. But if ACPI will start accessing fw_cfg from other methods it will race for sure.
