Re: [Xen-devel] [V10 PATCH 0/4] pvh dom0 patches...

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Fri, May 02, 2014 at 06:13:51PM +0200, Roger Pau Monné wrote:
> On 02/05/14 17:41, Jan Beulich wrote:
> >>>> On 02.05.14 at 16:35, <roger.pau@xxxxxxxxxx> wrote:
> >> On 02/05/14 16:16, Jan Beulich wrote:
> >>>>>> On 02.05.14 at 16:06, <roger.pau@xxxxxxxxxx> wrote:
> >>>> My bad, I've incorrectly printed this as 0x%lu instead of %lx, the
> >>>> following output is correct:
> >>>>
> >>>> SMAP type=01 base=0000000000000000 len=0000000000092400
> >>>> SMAP type=02 base=00000000000f0000 len=0000000000010000
> >>>> SMAP type=01 base=0000000000100000 len=000000003ff6e000
> >>>> SMAP type=04 base=00000000dfdf9c00 len=0000000000052000
> >>>> SMAP type=03 base=00000000dfe4bc00 len=0000000000002000
> >>>> SMAP type=02 base=00000000dfe4dc00 len=00000000001b2400
> >>>> SMAP type=02 base=00000000f8000000 len=0000000005000000
> >>>> SMAP type=02 base=00000000fe000000 len=0000000000d00400
> >>>> SMAP type=02 base=00000000fee00000 len=0000000000100000
> >>>> SMAP type=02 base=00000000ffb00000 len=0000000000500000
> >>>> SMAP type=02 base=0000000100000000 len=00000000a0000000
> > 
> > Considering the hypervisor view below, this range clearly is then
> > wrong here too, ...
> > 
> >> Maybe the problem is on FreeBSD, and I'm not correctly clamping the e820
> >> memory map returned by Xen. Right now I'm using start_info->nr_pages as
> >> the number of valid RAM pages assigned to Dom0, but it is not clear if
> >> start_info->nr_pages also takes into account the holes and invalid
> >> regions in the e820 memory map.
> > 
> > i.e. yes, there must be some kind of problem in your handling in any
> > case.
> > 
> >> This is the hw memory map reported by Xen:
> >>
> >> (XEN) Xen-e820 RAM map:
> >> (XEN)  0000000000000000 - 0000000000092400 (usable)
> >> (XEN)  00000000000f0000 - 0000000000100000 (reserved)
> >> (XEN)  0000000000100000 - 00000000dfdf9c00 (usable)
> >> (XEN)  00000000dfdf9c00 - 00000000dfe4bc00 (ACPI NVS)
> >> (XEN)  00000000dfe4bc00 - 00000000dfe4dc00 (ACPI data)
> >> (XEN)  00000000dfe4dc00 - 00000000e0000000 (reserved)
> >> (XEN)  00000000f8000000 - 00000000fd000000 (reserved)
> >> (XEN)  00000000fe000000 - 00000000fed00400 (reserved)
> >> (XEN)  00000000fee00000 - 00000000fef00000 (reserved)
> >> (XEN)  00000000ffb00000 - 0000000100000000 (reserved)
> >> (XEN)  0000000100000000 - 00000001a0000000 (usable)
> >>
> >> And the Dom0 is assigned 1024M of RAM.
> > 
> > I.e. it can have pages at or beyond 0x40000000 only if some other
> > region is unpopulated.
> 
> If I got this right, it means that the maximum populated gpfn on the
> domain is (start_info->nr_pages << PAGE_SHIFT), which is kind of odd,

So it is -1ULL without any dom0_mem=max:X arguments but if you
use dom0_mem=max:X it has a sensible value?

If you use 'dom0_mem=max:1GB" the nr_pages should be 262144.

> because on PVH Dom0 all the holes in the memory map are already set to
> p2m_mmio_direct (see pvh_map_all_iomem in patch 1), so I don't think
> there's anything I can unpopulate, and it means that the dom0_mem param
> passed in the command line is not properly handled, because the actual
> usable RAM assigned to the Dom0 will vary depending on the underlying
> hardware e820 map.

Right. The nr_pages will only correspond to the E820_RAM regions.

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

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