qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/6] x86: Physical address limit patches


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [PATCH v2 0/6] x86: Physical address limit patches
Date: Tue, 5 Jul 2016 13:41:50 +0100
User-agent: Mutt/1.6.1 (2016-04-27)

* Michael S. Tsirkin (address@hidden) wrote:
> On Tue, Jul 05, 2016 at 12:59:42PM +0200, Paolo Bonzini wrote:
> > 
> > 
> > On 05/07/2016 12:06, Michael S. Tsirkin wrote:
> > > >      -m 2G,slots=16,maxmem=2T
> > > > 
> > > > On a host with a 39bit physaddress limit do you error
> > > > on that or not?  I think oVirt is currently doing something
> > > > similar to that, but I'm trying to get confirmation.
> > > 
> > > That would only be a problem since pci is allocated above
> > > maxmem so 64 bit pci addresses aren't accessible.
> > > With my proposal we can actually force firmware to avoid
> > > using 64 bit memory for that config.
> > > Will work better than today.
> > 
> > So you would remove completely the 64-bit _CRS in this case?
> 
> Yes.
> 
> > How do you handle migration in the above scenario from say 46bit host to
> > 39bit host, where the firmware has mapped (while running on the source)
> > a 64-bit BAR above the destination's maximum physical address?
> > 
> > Thanks,
> > 
> > Paolo
> 
> Again management would specify how much 64 bit pci space firmware should use.
> If more is specified than host can support we can error out.

What stops the guest OS mapping PCI stuff high up - however much you change
the firmware?

Dave

> 
> -- 
> MST
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

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