Re: [Qemu-devel] [PATCH v5 5/5] nvdimm acpi: add _CRS

[Igor Mammedov]

On Mon, 7 Mar 2016 14:22:38 +0200
"Michael S. Tsirkin" <address@hidden> wrote:

> On Mon, Mar 07, 2016 at 01:16:48PM +0100, Igor Mammedov wrote:
> > On Thu, 3 Mar 2016 16:48:55 +0200
> > "Michael S. Tsirkin" <address@hidden> wrote:
> >   
> > > On Thu, Mar 03, 2016 at 10:05:31PM +0800, Xiao Guangrong wrote:  
> > > > 
> > > > 
> > > > On 03/03/2016 09:29 PM, Michael S. Tsirkin wrote:    
> > > > >On Wed, Mar 02, 2016 at 07:50:41PM +0800, Xiao Guangrong wrote:    
> > > > >>As Igor suggested that we can report the BIOS patched operation region
> > > > >>so that OSPM could see that particular range is in use and be able to
> > > > >>notice conflicts if it happens some day
> > > > >>
> > > > >>Signed-off-by: Xiao Guangrong <address@hidden>    
> > > > >
> > > > >This is reserved RAM, exposing it in _CRS makes no sense to me.    
> > > > 
> > > > As more and more memory will be reserved by BIOS/QEMU, report the
> > > > information to OSPM and let it check the potential error is bad,
> > > > no? :)    
> > > 
> > > guest has enough info to detect conflicts if it wishes to.
> > > IIUC _CRS is not intended for RAM, it's for MMIO
> > > resources, if it works for RAM that's an accident.  
> > If range isn't reserved here, then guest might assume that it's
> > free to use it for a PCI device since PCI0._CRS reports it
> > as available.  
> 
> Does it really? I thought it's guest RAM allocated by BIOS, as opposed
> to PCI memory. Am I wrong?
Maybe I'm wrong,
but aren't RAM and PCI memory mapped into the same physical address space?
So what would happen when PCI MMIO BAR would be mapped over above range,
since guest thinks it's free to use it as unused resource?


> 
> > So we should either reserve range or punch a hole in PCI0._CRS.
> > Reserving ranges is simpler and that's what we've switched to
> > from manual hole punching, see PCI/CPU/Memory hotplug and other
> > motherboard resources.