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: Monday, August 20, 2012 6:45 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 20.08.12 at 05:22, "Hao, Xudong" <xudong.hao@xxxxxxxxx> wrote:
> 
> >> -----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.
> >>
> >
> > Where does present the 36-bit physical addresses limit, could you help to
> > point out in the current Xen code?
> 
> Look at xen/arch/x86/hvm/mtrr.c, e.g. hvm_mtrr_pat_init() or
> mtrr_var_range_msr_set().

So if common 36-bit(guest) physical address could not change, can we use top 
down from 64G, Jan, do you have any suggestion? 

Thanks,
-Xudong

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