[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/3] xen/tools: Add 64 bits big bar support
> -----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(). I think BIOS may fix it, you can refer to tools/firmware/hvmloader/cacheattr.c, and BIOS can set to right phys bit number after check. Xiantao _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |