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 <kra...@redhat.com> > > > > > > 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
