qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Igor Mammedov
Subject: Re: [Qemu-devel] RFC: guest-side retrieval of fw_cfg file
Date: Thu, 16 Jul 2015 13:15:17 +0200

On Thu, 16 Jul 2015 13:25:56 +0300
"Michael S. Tsirkin" <address@hidden> wrote:

> 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" <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.
> 
> vm gen id? No, its dynamic.
nope, I've mean address of buffer, not UUID itself.
 
> > > 
> > > > 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.
yep they do,
except of that they are more complex on ACPI side and
it's more difficult to debug. I like the last revision of
series for simplicity of design and behavior.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]