On Thu, Jul 16, 2015 at 11:50:38AM +0200, Igor Mammedov wrote: > On Thu, 16 Jul 2015 10:30:41 +0300 > "Michael S. Tsirkin" <m...@redhat.com> 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" <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? > I've thought that it's pretty static and doesn't change.
vm gen id? No, its dynamic. > > > > > 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. > Other versions just write into guest memory from QEMU, that will work fine too. -- MST
