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" <mst@xxxxxxxxxx> 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 <guangrong.xiao@xxxxxxxxxxxxxxx> > > > > > > > >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? > 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
