Re: [Xen-devel] [PATCH 1/3] xen/tools: Add 64 bits big bar support

["Hao, Xudong" <xudong.hao@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Friday, August 17, 2012 5:36 PM
> To: Hao, Xudong
> Cc: ian.jackson@xxxxxxxxxxxxx; Zhang, Xiantao; xen-devel@xxxxxxxxxxxxx
> Subject: RE: [Xen-devel] [PATCH 1/3] xen/tools: Add 64 bits big bar support
> 
> >>> On 17.08.12 at 11:24, "Hao, Xudong" <xudong.hao@xxxxxxxxx> wrote:
> >>  -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: Thursday, August 16, 2012 7:04 PM
> >> To: Hao, Xudong
> >> Cc: ian.jackson@xxxxxxxxxxxxx; Zhang, Xiantao; xen-devel@xxxxxxxxxxxxx
> >> Subject: RE: [Xen-devel] [PATCH 1/3] xen/tools: Add 64 bits big bar support
> >>
> >> >>> On 16.08.12 at 12:48, "Hao, Xudong" <xudong.hao@xxxxxxxxx> wrote:
> >> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> >> >>> On 15.08.12 at 08:54, Xudong Hao <xudong.hao@xxxxxxxxx> wrote:
> >> >> > --- a/tools/firmware/hvmloader/config.h       Tue Jul 24 17:02:04 2012
> >> +0200
> >> >> > +++ b/tools/firmware/hvmloader/config.h       Thu Jul 26 15:40:01 2012
> >> +0800
> >> >> > @@ -53,6 +53,10 @@ extern struct bios_config ovmf_config;
> >> >> >  /* MMIO hole: Hardcoded defaults, which can be dynamically
> expanded.
> >> */
> >> >> >  #define PCI_MEM_START       0xf0000000
> >> >> >  #define PCI_MEM_END         0xfc000000
> >> >> > +#define PCI_HIGH_MEM_START  0xa000000000ULL
> >> >> > +#define PCI_HIGH_MEM_END    0xf000000000ULL
> >> >>
> >> >> With such hard coded values, this is hardly meant to be anything
> >> >> more than an RFC, is it? These values should not exist in the first
> >> >> place, and the variables below should be determined from VM
> >> >> characteristics (best would presumably be to allocate them top
> >> >> down from the end of physical address space, making sure you
> >> >> don't run into RAM).
> >>
> >> No comment on this part?
> >>
> >
> > The MMIO high memory start from 640G, it's already very high, I think we
> > don't need allocate MMIO top down from the high of physical address space.
> > Another thing you remind me that maybe we can skip this high MMIO hole
> when
> > setup p2m table in build hvm of libxc(setup_guest()), like the handles for
> > MMIO below 4G.
> 
> That would be an option, but any fixed address you pick here
> will look arbitrary (and will sooner or later raise questions). Plus
> by allowing the RAM above 4G to remain contiguous even for
> huge guests, we'd retain maximum compatibility with all sorts
> of guest OSes. Furthermore, did you check that we in all cases
> can use 40-bit (guest) physical addresses (I would think that 36
> is the biggest common value). Bottom line - please don't use a
> fixed number here.
> 

Hi, Jan

Where does present the 36-bit physical addresses limit, could you help to point 
out in the current Xen code?

Thanks,
-Xudong

> Jan

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