[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable devic
From: |
Ian Campbell |
Subject: |
Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M |
Date: |
Wed, 12 Jun 2013 09:31:25 +0100 |
On Wed, 2013-06-12 at 08:25 +0100, Jan Beulich wrote:
> >>> On 11.06.13 at 19:26, Stefano Stabellini <address@hidden> wrote:
> > I went through the code that maps the PCI MMIO regions in hvmloader
> > (tools/firmware/hvmloader/pci.c:pci_setup) and it looks like it already
> > maps the PCI region to high memory if the PCI bar is 64-bit and the MMIO
> > region is larger than 512MB.
> >
> > Maybe we could just relax this condition and map the device memory to
> > high memory no matter the size of the MMIO region if the PCI bar is
> > 64-bit?
>
> I can only recommend not to: For one, guests not using PAE or
> PSE-36 can't map such space at all (and older OSes may not
> properly deal with 64-bit BARs at all). And then one would generally
> expect this allocation to be done top down (to minimize risk of
> running into RAM), and doing so is going to present further risks of
> incompatibilities with guest OSes (Linux for example learned only in
> 2.6.36 that PFNs in ioremap() can exceed 32 bits, but even in
> 3.10-rc5 ioremap_pte_range(), while using "u64 pfn", passes the
> PFN to pfn_pte(), the respective parameter of which is
> "unsigned long").
>
> I think this ought to be done in an iterative process - if all MMIO
> regions together don't fit below 4G, the biggest one should be
> moved up beyond 4G first, followed by the next to biggest one
> etc.
>
> And, just like many BIOSes have, there ought to be a guest
> (config) controlled option to shrink the RAM portion below 4G
> allowing more MMIO blocks to fit.
>
> Finally we shouldn't forget the option of not doing any assignment
> at all in the BIOS, allowing/forcing the OS to use suitable address
> ranges. Of course any OS is permitted to re-assign resources, but
> I think they will frequently prefer to avoid re-assignment if already
> done by the BIOS.
Is "bios=assign-busses" on the guest command line suitable as a
workaround then? Or possibly "bios=realloc"
Ian.
- Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M, Stefano Stabellini, 2013/06/11
- Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M, Jan Beulich, 2013/06/12
- Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M,
Ian Campbell <=
- Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M, Jan Beulich, 2013/06/12
- Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M, Ian Campbell, 2013/06/12
- Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M, Jan Beulich, 2013/06/12
- Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M, Ian Campbell, 2013/06/12
- Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M, Jan Beulich, 2013/06/12
- Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M, Ian Campbell, 2013/06/12
Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M, George Dunlap, 2013/06/12
Re: [Qemu-devel] [Xen-devel] [BUG 1747]Guest could't find bootable device with memory more than 3600M, Paolo Bonzini, 2013/06/12