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

Re: [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M



On 06/07/2013 01:15 PM, Stefano Stabellini wrote:
On Fri, 7 Jun 2013, Xu, YongweiX wrote:
Hi Stefano Stabellini,

I found a new bug "Guest could't find bootable device with memory more than 
3600M".
Attach the link:  
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1857

When booting up guest(include Linux&Windows guest) with memory more than 3600M,the guest 
will show "No bootable device" and could not boot up. Then the guest will 
continuous reboot automatically and never found bootable device. But with guest memory less 
than or equal to 3600M, boot up successfully.

I found this is the qemu(qemu-upstream-unstable) issue, the latest version 
(commit:4597594c61add43725bd207bb498268a058f9cfb) caused this issue:
xen: start PCI hole at 0xe0000000 (same as pc_init1 and qemu-xen-traditional)
author      Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
            Wed, 5 Jun 2013 19:36:10 +0800 (11:36 +0000)
committer   Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
            Wed, 5 Jun 2013 19:36:10 +0800 (11:36 +0000)
commit     4597594c61add43725bd207bb498268a058f9cfb
tree        d6831f75f4a7d4ad7a94bd4e33584ac358808ee6
parent      25adf763933faddcc6a62bf55e1c52909a9bafbb

Can you debug this issue soon? Thanks.

Thank you very much for testing and bisecting the issue!

The problem is that by default hvmloader sets PCI_MEM_START to
0xf0000000, then dynamically expands it backwards if needed.
It works with qemu-xen-traditional, because it doesn't do any checking
when registering memory regions.
It doesn't work with qemu-xen because it needs to know where the ram and
where the pci hole are when building the emulated machine.
We can't have hvmloader increasing the pci hole in a way that overlaps
with the guest ram (or where qemu thinks that the guest ram is).
It is also worth noting thet seabios has its own view of where the pci
hole starts and at the moment is set to 0xe0000000 at build time.

I can see two ways of fixing this now:

1) have everybody agree about the pci hole starting at 0xe0000000

- set PCI_MEM_START in hvmloader to 0xe0000000 to match qemu's view of
the pci hole and have a bigger pci hole by default

- remove the loop in hvmloader to increase the pci hole

- set HVM_BELOW_4G_RAM_END to 0xe0000000, so that low_mem_pgend is set
accordingly in tools/libxc/xc_hvm_build_x86.c:build_hvm_info


2) have everybody agree about the pci hole starting at 0xf0000000

- revert 4597594c61add43725bd207bb498268a058f9cfb in qemu-xen

- set BUILD_PCIMEM_START to 0xf0000000 in seabios

- remove the loop in hvmloader to increase the pci hole


Given that in both cases we need to remove the loop to increase the pci
hole in hvmloader I would rather go with 1) and have a bigger pci hole
by default to avoid problems with the pci hole being too small.


Did we ever figure out what actually happens on real hardware? Or on KVM? I have a hard time believing that real hardware is hard-coded -- who would be the person to ask about that, do you reckon?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.