qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] pci: fix pci bridge fw path


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH] pci: fix pci bridge fw path
Date: Mon, 09 Dec 2013 11:00:56 +0100

On Mo, 2013-12-09 at 11:24 +0200, Marcel Apfelbaum wrote:
> On Mon, 2013-12-09 at 08:14 +0100, Gerd Hoffmann wrote:
> > On So, 2013-12-08 at 13:31 +0200, Michael S. Tsirkin wrote:
> > > On Fri, Dec 06, 2013 at 12:24:40PM +0100, Gerd Hoffmann wrote:
> > > > qemu uses "pci" as name for pci bridges in the firmware device path.
> > > > seabios expects "pci-bridge".  Result is that bootorder is broken for
> > > > devices behind pci bridges.
> > > > 
> > > > Some googling suggests that "pci-bridge" is the correct one.  At least
> > > > PPC-based Apple machines are using this.  See question "How do I boot
> > > > from a device attached to a PCI card" here:
> > > >         http://www.netbsd.org/ports/macppc/faq.html
> > > > 
> > > > So lets change qemu to use "pci-bridge" too.
> > > > 
> > > > Signed-off-by: Gerd Hoffmann <address@hidden>
> > > 
> > > Sounds good but this needs to be enabled for
> > > new machine types only - otherwise guest will read
> > > corrupted data since bootindex is in FW CFG.
> > 
> > Come on, that is seriously over-engineering.
> Does this change affects migration in any way?

If you live-migrate from a machine without the fix to a machine with the
fix *and* you have bootorder configured for a device behind the pci
bridge then size of the etc/bootorder fw_cfg file will change.

So, in case of the following event sequence ...

  (a) firmware reads fw_fg directory index (with file sizes)
  (b) live migration
  (c) firmware reads etc/bootorder

... the firmware will read the new content with old size, i.e. it will
miss a few bytes or have trailing garbage (or zeros?  Not sure what qemu
emulation does if you read over the end of a fw_cfg files).

Result might be that bootorder isn't applied correctly.  But that is the
case _anyway_ on the machine with the unfixed qemu version.  So making
this machine type dependent buys us nothing but churn for no reason.

cheers,
  Gerd





reply via email to

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