Re: [Xen-devel] [PATCH OSSTEST 02/12] Increase boot timer to accomodate to nest test

> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: Wednesday, February 11, 2015 10:47 PM > To: Hu, Robert > Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com; > ian.campb...@citrix.com; Pang, LongtaoX > Subject: Re: [PATCH OSSTEST 02/12] In

[Xen-devel] PML (Page Modification Logging) design for Xen

​>On 12/02/15 06:54, Tian, Kevin wrote: >> which presumably means that the PML buffer flush needs to be aware of which gfns are mapped by superpages to be able to correctly set a block of bits in the logdirty bitmap. >>> Unfortunately PML itself can't tell us if the logged

Re: [Xen-devel] [PATCH OSSTEST 05/12] Add and expose some testsupport APIs

> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: Wednesday, February 11, 2015 10:54 PM > To: Hu, Robert > Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com; > ian.campb...@citrix.com; Pang, LongtaoX > Subject: Re: [PATCH OSSTEST 05/12] Add

Re: [Xen-devel] [PATCH OSSTEST 03/12] Designate vif device model to e1000

> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: Wednesday, February 11, 2015 10:50 PM > To: Hu, Robert > Cc: xen-devel@lists.xen.org; jfeh...@suse.com; wei.l...@citrix.com; > ian.campb...@citrix.com; Pang, LongtaoX > Subject: Re: [PATCH OSSTEST 03/12] Des

Re: [Xen-devel] [PATCH OSSTEST 06/12] Manipulate $ho IP assignment for nest L2 situation

> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: Wednesday, February 11, 2015 10:59 PM > To: Hu, Robert > Cc: xen-devel@lists.xen.org; ian.jack...@eu.citrix.com; jfeh...@suse.com; > wei.l...@citrix.com; ian.campb...@citrix.com; Pang, LongtaoX > Subject: R

Re: [Xen-devel] [PATCH v5 23/24] xl: introduce xcalloc

On Thu, Feb 12, 2015 at 08:17:42PM +, Andrew Cooper wrote: > On 12/02/15 19:44, Wei Liu wrote: > > Signed-off-by: Wei Liu > > Cc: Ian Campbell > > Cc: Ian Jackson > > --- > > tools/libxl/xl_cmdimpl.c | 12 > > 1 file changed, 12 insertions(+) > > > > diff --git a/tools/libxl/xl

Re: [Xen-devel] [PATCH] tools/Coverity: Audit of MISSING_BREAK defects

On Thu, Feb 12, 2015 at 08:08:33PM +, Andrew Cooper wrote: > Coverity uses several heuristics to identify when one case statement > legitimately falls through into the next, and a comment as the final item in a > case statement is one heuristic (the assumption being that it is a > justification

Re: [Xen-devel] [PATCH] tools/Coverity: Audit of MISSING_BREAK defects

On 12/02/15 20:49, Don Koch wrote: > On Thu, 12 Feb 2015 20:08:33 + > Andrew Cooper wrote: > >> Coverity uses several heuristics to identify when one case statement >> legitimately falls through into the next, and a comment as the final item in >> a >> case statement is one heuristic (the ass

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

On 13/02/15 02:11, Kai Huang wrote: > > On 02/12/2015 10:10 PM, Andrew Cooper wrote: >> On 12/02/15 06:54, Tian, Kevin wrote: > which presumably > means that the PML buffer flush needs to be aware of which gfns are > mapped by superpages to be able to correctly set a block of bits in th

Re: [Xen-devel] [PATCH] xen/Coverity: Audit of MISSING_BREAK defects

On 12/02/15 21:06, Don Koch wrote: > On Thu, 12 Feb 2015 20:08:46 + > Andrew Cooper wrote: > >> Coverity uses several heuristics to identify when one case statement >> legitimately falls through into the next, and a comment as the final item in >> a >> case statement is one heuristic (the ass

Re: [Xen-devel] freemem-slack and large memory environments

On Tue, Feb 10, 2015 at 02:34:27PM -0700, Mike Latimer wrote: > On Monday, February 09, 2015 06:27:54 PM Mike Latimer wrote: > > While testing commit 2563bca1, I found that libxl_get_free_memory returns 0 > > until there is more free memory than required for freemem-slack. This means > > that durin

Re: [Xen-devel] [PATCH v3] libxl: Wait for ballooning if free memory is increasing

On Tue, Feb 10, 2015 at 09:17:23PM -0700, Mike Latimer wrote: > On Thursday, February 05, 2015 12:45:53 PM Ian Campbell wrote: > > On Mon, 2015-02-02 at 08:17 -0700, Mike Latimer wrote: > > > On Monday, February 02, 2015 02:35:39 PM Ian Campbell wrote: > > > > On Fri, 2015-01-30 at 14:01 -0700, Mik

Re: [Xen-devel] [PATCH RFC 00/20] Change parts of the shadow interface to be domain based

On 12/02/15 17:15, Andrew Cooper wrote: > The entire series has been compile tested at each changeset, for both > shadow-paging=y and n. It has also been tested internally in XenServer, but > appears to have gotten caught up in some collateral damage from an unrelated > merge. I am rerunning the

Re: [Xen-devel] [PATCH OSSTEST 02/12] Increase boot timer to accomodate to nest test

Hu, Robert writes ("RE: [PATCH OSSTEST 02/12] Increase boot timer to accomodate to nest test"): > > Robert Ho writes ("[PATCH OSSTEST 02/12] Increase boot timer to accomodate > > to nest test"): > > > In nested test case, guest boot will take more time. > > > Increase the timer to 200 seconds. >

Re: [Xen-devel] [PATCH v5 01/24] xen: dump vNUMA information with debug key "u"

On 12/02/15 19:44, Wei Liu wrote: > Signed-off-by: Elena Ufimsteva > Signed-off-by: Wei Liu > Cc: Jan Beulich Reviewed-by: Andrew Cooper > --- > Changes in v5: > 1. Use read_trylock. > 2. Use correct array size for strlcpy. > 3. Coding style fix. > > Changes in v4: > 1. Acquire rwlock before

Re: [Xen-devel] [PATCH v5 02/24] xen: make two memory hypercalls vNUMA-aware

On 12/02/15 19:44, Wei Liu wrote: > Make XENMEM_increase_reservation and XENMEM_populate_physmap > vNUMA-aware. > > That is, if guest requests Xen to allocate memory for specific vnode, > Xen can translate vnode to pnode using vNUMA information of that guest. > > XENMEMF_vnode is introduced for the

Re: [Xen-devel] [PATCH OSSTEST 11/12] Changes on test step of debain hvm guest install

Hu, Robert writes ("RE: [PATCH OSSTEST 11/12] Changes on test step of debain hvm guest install"): > [Ian] > > Firstly, can you please reformat your commit message so that the > > individual points are separated out into paragraphs. But I think > > actually that probably some of this wants to go i

Re: [Xen-devel] [PATCH V4 13/13] xen/vm_event: Add RESUME option to vm_event_op domctl

On Mon, Feb 09, 2015 at 07:53:38PM +0100, Tamas K Lengyel wrote: > Thus far mem_access and mem_sharing memops had been able to signal > to Xen to start pulling responses off the corresponding rings. In this patch > we retire these memops and add them to the option to the vm_event_op domctl. > > Th

Re: [Xen-devel] [PATCH V4 05/13] xen: Rename mem_event to vm_event

On Mon, Feb 09, 2015 at 07:53:30PM +0100, Tamas K Lengyel wrote: > In this patch we mechanically rename mem_event to vm_event. This patch > introduces no logic changes to the code. Using the name vm_event better > describes the intended use of this subsystem, which is not limited to memory > events

[Xen-devel] [ovmf test] 34487: regressions - FAIL

flight 34487 ovmf real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34487/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 33686 test-amd64-i386-xl-qemuu-ovm

[Xen-devel] [rumpuserxen test] 34501: regressions - FAIL

flight 34501 rumpuserxen real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34501/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866 build-amd64-rumpuserx

Re: [Xen-devel] [PATCH v3 3/7] sysctl: Make topologyinfo and numainfo sysctls a little more efficient

On Mon, Feb 09, 2015 at 03:04:31PM -0500, Boris Ostrovsky wrote: > Currently both of these sysctls make a copy to userspace for each index of > various query arrays. We should try to copy whole arrays instead. > > This requires some changes in sysctl's public data structure, thus bump > interface

Re: [Xen-devel] [PATCH v3 7/7] libxl: Add interface for querying hypervisor about PCI topology

On Mon, Feb 09, 2015 at 03:04:35PM -0500, Boris Ostrovsky wrote: [...] > +#ifdef LIBXL_HAVE_PCITOPO > +libxl_pcitopology *libxl_get_pci_topology(libxl_ctx *ctx, int *num_devs) > +{ > +GC_INIT(ctx); > +physdev_pci_device_t *devs; > +uint8_t *nodes; > +libxl_pcitopology *ret = NULL;

Re: [Xen-devel] [PATCH v9 3/3] tools, docs: add total/local memory bandwith monitoring

On Mon, Feb 02, 2015 at 04:06:09PM +0800, Chao Peng wrote: > Add Memory Bandwidth Monitoring(MBM) for VMs. Two types of monitoring > are supported: total and local memory bandwidth monitoring. To use it, > CMT should be enabled in hypervisor. > > Signed-off-by: Chao Peng > --- > Changes in v9: >

Re: [Xen-devel] [PATCH] tools/hotplug: introduce XENSTORED_ARGS= in sysconfig file.

Olaf Hering writes ("[PATCH] tools/hotplug: introduce XENSTORED_ARGS= in sysconfig file."): > It is already used in the runlevel script and the service file. It is > supposed to replace XENSTORED_TRACE= boolean, which cant be easily > supported in the xenstored.service file. I haven't gone throu

Re: [Xen-devel] [PATCH v5 02/24] xen: make two memory hypercalls vNUMA-aware

On Fri, Feb 13, 2015 at 12:00:29PM +, Andrew Cooper wrote: [...] > > +static int translate_vnode_to_pnode(struct domain *d, > > +struct xen_memory_reservation *r, > > const struct xen_memory_reservation *r > Ack. > > +s

[Xen-devel] [libvirt test] 34500: regressions - FAIL

flight 34500 libvirt real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34500/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 13 guest-destroy fail REGR. vs. 34464 Regressions which are reg

Re: [Xen-devel] [PATCH v5 22/24] libxlu: introduce new APIs

Wei Liu writes ("[PATCH v5 22/24] libxlu: introduce new APIs"): > These APIs can be used to manipulate XLU_ConfigValue and XLU_ConfigList. > > +if (value->type != XLU_STRING) { > +if (!dont_warn) > +fprintf(cfg->report, "warning: value is not a string\n"); > +*value

Re: [Xen-devel] [PATCH v5 19/24] libxl: define LIBXL_HAVE_VNUMA

Wei Liu writes ("[PATCH v5 19/24] libxl: define LIBXL_HAVE_VNUMA"): > Signed-off-by: Wei Liu ... > +/* LIBXL_HAVE_VNUMA > + * > + * If it is defined, libxl supports vNUMA configuration > + */ I think you should be more specific about which calls are covered. Ian. ___

Re: [Xen-devel] [PATCH v5 08/24] libxl: introduce libxl__vnuma_config_check

Wei Liu writes ("[PATCH v5 08/24] libxl: introduce libxl__vnuma_config_check"): > This function is used to check whether vNUMA configuration (be it > auto-generated or supplied by user) is valid. This looks plausible, but I think you should explain what the impact of this patch is. Presumably the

Re: [Xen-devel] [PATCH v5 18/24] libxl: disallow memory relocation when vNUMA is enabled

Wei Liu writes ("[PATCH v5 18/24] libxl: disallow memory relocation when vNUMA is enabled"): > Disallow memory relocation when vNUMA is enabled, because relocated > memory ends up off node. Further more, even if we dynamically expand > node coverage in hvmloader, low memory and high memory may res

Re: [Xen-devel] [PATCH v5 17/24] libxl: build, check and pass vNUMA info to Xen for HVM guest

Wei Liu writes ("[PATCH v5 17/24] libxl: build, check and pass vNUMA info to Xen for HVM guest"): > Transform user supplied vNUMA configuration into libxl internal > representations then libxc representations. Check validity along the > line. This is going to be a totally stupid question: but why

Re: [Xen-devel] [PATCH v3 3/7] sysctl: Make topologyinfo and numainfo sysctls a little more efficient

On 02/13/2015 07:26 AM, Wei Liu wrote: On Mon, Feb 09, 2015 at 03:04:31PM -0500, Boris Ostrovsky wrote: Currently both of these sysctls make a copy to userspace for each index of various query arrays. We should try to copy whole arrays instead. This requires some changes in sysctl's public data

Re: [Xen-devel] [PATCH v3 7/7] libxl: Add interface for querying hypervisor about PCI topology

On 02/13/2015 07:43 AM, Wei Liu wrote: On Mon, Feb 09, 2015 at 03:04:35PM -0500, Boris Ostrovsky wrote: [...] +#ifdef LIBXL_HAVE_PCITOPO +libxl_pcitopology *libxl_get_pci_topology(libxl_ctx *ctx, int *num_devs) +{ +GC_INIT(ctx); +physdev_pci_device_t *devs; +uint8_t *nodes; +lib

Re: [Xen-devel] [PATCH v5 20/24] libxlu: rework internal representation of setting

Wei Liu writes ("[PATCH v5 20/24] libxlu: rework internal representation of setting"): > This patches does following things: Thanks, Acked-by: Ian Jackson ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xen/Coverity: Audit of MISSING_BREAK defects

On Fri, 13 Feb 2015 11:01:27 + Andrew Cooper wrote: > On 12/02/15 21:06, Don Koch wrote: > > On Thu, 12 Feb 2015 20:08:46 + > > Andrew Cooper wrote: > > [...] > > I'm surprised that coverity didn't complain about the fallthrough in > > the next case: > > > > case TASKLET_scheduled: >

[Xen-devel] [qemu-mainline test] 34490: regressions - FAIL

flight 34490 qemu-mainline real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34490/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 33480 test-amd64-amd

Re: [Xen-devel] [PATCH v5 05/24] libxc: allocate memory with vNUMA information for PV guest

On 12/02/15 19:44, Wei Liu wrote: > diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h > index 45b8644..1809674 100644 > --- a/tools/libxc/xc_private.h > +++ b/tools/libxc/xc_private.h > @@ -35,6 +35,8 @@ > > #include > > +#define XC_VNUMA_NO_NODE (~0U) Shouldn't this sentinel

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

On Fri, Feb 13, 2015 at 6:57 PM, Andrew Cooper wrote: > On 13/02/15 02:11, Kai Huang wrote: > > > On 02/12/2015 10:10 PM, Andrew Cooper wrote: > > On 12/02/15 06:54, Tian, Kevin wrote: > > which presumably > means that the PML buffer flush needs to be aware of which gfns are > mapped by superpages

Re: [Xen-devel] [PATCH] domctl: do away with tool stack based retrying

On Wed, Feb 11, 2015 at 01:47:09PM +, Jan Beulich wrote: > XEN_DOMCTL_destroydomain so far is being special cased in libxc to > reinvoke the operation when getting back EAGAIN. Quite a few other > domctl-s have gained continuations, so I see no reason not to use them > here too. > > Signed-off

Re: [Xen-devel] [PATCH v5 05/24] libxc: allocate memory with vNUMA information for PV guest

On Fri, Feb 13, 2015 at 02:30:30PM +, Andrew Cooper wrote: > On 12/02/15 19:44, Wei Liu wrote: > > diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h > > index 45b8644..1809674 100644 > > --- a/tools/libxc/xc_private.h > > +++ b/tools/libxc/xc_private.h > > @@ -35,6 +35,8 @@ > >

Re: [Xen-devel] [PATCH v5 08/24] libxl: introduce libxl__vnuma_config_check

On Fri, Feb 13, 2015 at 02:15:47PM +, Ian Jackson wrote: > Wei Liu writes ("[PATCH v5 08/24] libxl: introduce > libxl__vnuma_config_check"): > > This function is used to check whether vNUMA configuration (be it > > auto-generated or supplied by user) is valid. > > This looks plausible, but I

Re: [Xen-devel] [PATCH v5 05/24] libxc: allocate memory with vNUMA information for PV guest

On 13/02/15 15:05, Wei Liu wrote: > On Fri, Feb 13, 2015 at 02:30:30PM +, Andrew Cooper wrote: >> On 12/02/15 19:44, Wei Liu wrote: >>> diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h >>> index 45b8644..1809674 100644 >>> --- a/tools/libxc/xc_private.h >>> +++ b/tools/libxc/xc_

Re: [Xen-devel] [PATCH v5 17/24] libxl: build, check and pass vNUMA info to Xen for HVM guest

On Fri, Feb 13, 2015 at 02:21:27PM +, Ian Jackson wrote: > Wei Liu writes ("[PATCH v5 17/24] libxl: build, check and pass vNUMA info to > Xen for HVM guest"): > > Transform user supplied vNUMA configuration into libxl internal > > representations then libxc representations. Check validity alon

Re: [Xen-devel] [PATCH v5 18/24] libxl: disallow memory relocation when vNUMA is enabled

On Fri, Feb 13, 2015 at 02:17:40PM +, Ian Jackson wrote: > Wei Liu writes ("[PATCH v5 18/24] libxl: disallow memory relocation when > vNUMA is enabled"): > > Disallow memory relocation when vNUMA is enabled, because relocated > > memory ends up off node. Further more, even if we dynamically ex

Re: [Xen-devel] [PATCH v5 19/24] libxl: define LIBXL_HAVE_VNUMA

On Fri, Feb 13, 2015 at 02:12:58PM +, Ian Jackson wrote: > Wei Liu writes ("[PATCH v5 19/24] libxl: define LIBXL_HAVE_VNUMA"): > > Signed-off-by: Wei Liu > ... > > +/* LIBXL_HAVE_VNUMA > > + * > > + * If it is defined, libxl supports vNUMA configuration > > + */ > > I think you should be more

Re: [Xen-devel] [PATCH v5 19/24] libxl: define LIBXL_HAVE_VNUMA

Ian Jackson writes ("Re: [PATCH v5 19/24] libxl: define LIBXL_HAVE_VNUMA"): > Yes, something like that. It would be better if the precise wording > were more similar to that for the other HAVE macros. How about: > >* If this is defined the type libxl_vnode_info exists, and a >* field 'vn

Re: [Xen-devel] [PATCH v5 19/24] libxl: define LIBXL_HAVE_VNUMA

Wei Liu writes ("Re: [PATCH v5 19/24] libxl: define LIBXL_HAVE_VNUMA"): > There is no new API yet. Just new structure to specify vNUMA > configuration. > > How about this: > > /* LIBXL_HAVE_VNUMA > * > * If this is defined, libxl's IDL has libxl_vnode_info and there is a > * array call vnuma_n

Re: [Xen-devel] [PATCH v5 19/24] libxl: define LIBXL_HAVE_VNUMA

On Fri, Feb 13, 2015 at 03:26:49PM +, Ian Jackson wrote: > Wei Liu writes ("Re: [PATCH v5 19/24] libxl: define LIBXL_HAVE_VNUMA"): > > There is no new API yet. Just new structure to specify vNUMA > > configuration. > > > > How about this: > > > > /* LIBXL_HAVE_VNUMA > > * > > * If this is d

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

On 13/02/15 14:32, Kai Huang wrote: > On Fri, Feb 13, 2015 at 6:57 PM, Andrew Cooper > wrote: >> On 13/02/15 02:11, Kai Huang wrote: >> >> >> On 02/12/2015 10:10 PM, Andrew Cooper wrote: >> >> On 12/02/15 06:54, Tian, Kevin wrote: >> >> which presumably >> means that the PML buffer flush needs to

Re: [Xen-devel] [PATCH V4] x86 spinlock: Fix memory corruption on completing completions

On 02/13, Raghavendra K T wrote: > > @@ -164,7 +161,7 @@ static inline int arch_spin_is_locked(arch_spinlock_t > *lock) > { > struct __raw_tickets tmp = READ_ONCE(lock->tickets); > > - return tmp.tail != tmp.head; > + return tmp.tail != (tmp.head & ~TICKET_SLOWPATH_FLAG); > } Well

Re: [Xen-devel] [PATCH v5 08/24] libxl: introduce libxl__vnuma_config_check

On Fri, Feb 13, 2015 at 10:12 AM, Wei Liu wrote: > On Fri, Feb 13, 2015 at 02:15:47PM +, Ian Jackson wrote: >> Wei Liu writes ("[PATCH v5 08/24] libxl: introduce >> libxl__vnuma_config_check"): >> > This function is used to check whether vNUMA configuration (be it >> > auto-generated or suppl

Re: [Xen-devel] [PATCH v5 08/24] libxl: introduce libxl__vnuma_config_check

On 12/02/15 19:44, Wei Liu wrote: > This function is used to check whether vNUMA configuration (be it > auto-generated or supplied by user) is valid. > > Define a new error code ERROR_VNUMA_CONFIG_INVALID. > > The checks performed can be found in the comment of the function. > > This vNUMA function

Re: [Xen-devel] [PATCH V4] x86 spinlock: Fix memory corruption on completing completions

On 02/13, Oleg Nesterov wrote: > > On 02/13, Raghavendra K T wrote: > > > > @@ -772,7 +773,8 @@ __visible void kvm_lock_spinning(struct arch_spinlock > > *lock, __ticket_t want) > > * check again make sure it didn't become free while > > * we weren't looking. > > */ > > - if (ACCE

Re: [Xen-devel] [PATCH v5 09/24] libxl: x86: factor out e820_host_sanitize

On 12/02/15 19:44, Wei Liu wrote: > This function gets the machine E820 map and sanitize it according to PV > guest configuration. > > This will be used in later patch. No functional change introduced in > this patch. > > Signed-off-by: Wei Liu > Cc: Ian Campbell > Cc: Ian Jackson > Cc: Dario Fa

Re: [Xen-devel] [PATCH v5 10/24] libxl: functions to build vmemranges for PV guest

On 12/02/15 19:44, Wei Liu wrote: > Introduce a arch-independent routine to generate one vmemrange per > vnode. Also introduce arch-dependent routines for different > architectures because part of the process is arch-specific -- ARM has > yet have NUMA support and E820 is x86 only. > > For those x8

Re: [Xen-devel] PML (Page Modification Logging) design for Xen

On Fri, Feb 13, 2015 at 11:28 PM, Andrew Cooper wrote: > On 13/02/15 14:32, Kai Huang wrote: >> On Fri, Feb 13, 2015 at 6:57 PM, Andrew Cooper >> wrote: >>> On 13/02/15 02:11, Kai Huang wrote: >>> >>> >>> On 02/12/2015 10:10 PM, Andrew Cooper wrote: >>> >>> On 12/02/15 06:54, Tian, Kevin wrote: >

Re: [Xen-devel] [PATCH v5 11/24] libxl: build, check and pass vNUMA info to Xen for PV guest

On 12/02/15 19:44, Wei Liu wrote: > Transform the user supplied vNUMA configuration into libxl internal > representations, and finally libxc representations. Check validity of > the configuration along the line. > > Signed-off-by: Wei Liu > Cc: Ian Campbell > Cc: Ian Jackson > Cc: Dario Faggioli

Re: [Xen-devel] [PATCH v5 12/24] hvmloader: retrieve vNUMA information from hypervisor

On 12/02/15 19:44, Wei Liu wrote: > Hvmloader issues XENMEM_get_vnumainfo hypercall and stores the > information retrieved in scratch space for later use. > > Signed-off-by: Wei Liu > Cc: Jan Beulich > --- > Changes in v5: > 1. Group scratch_alloc togeter. > 2. Use memset. > 3. Drop unnecessary "

Re: [Xen-devel] [PATCH v5 08/24] libxl: introduce libxl__vnuma_config_check

On Fri, Feb 13, 2015 at 10:39:25AM -0500, Elena Ufimtseva wrote: > On Fri, Feb 13, 2015 at 10:12 AM, Wei Liu wrote: > > On Fri, Feb 13, 2015 at 02:15:47PM +, Ian Jackson wrote: > >> Wei Liu writes ("[PATCH v5 08/24] libxl: introduce > >> libxl__vnuma_config_check"): > >> > This function is us

Re: [Xen-devel] [PATCH v5 13/24] hvmloader: construct SRAT

On 12/02/15 19:44, Wei Liu wrote: > Signed-off-by: Wei Liu > Acked-by: Jan Beulich > --- > Changes in v3: > 1. Remove redundant variable. > 2. Coding style fix. > 3. Add assertion. > > Changes in v2: > 1. Remove explicit zero initializers. > 2. Adapt to new vNUMA retrieval routine. > 3. Move SRAT

Re: [Xen-devel] [PATCH v5 14/24] hvmloader: construct SLIT

On 12/02/15 19:44, Wei Liu wrote: > Signed-off-by: Wei Liu > Acked-by: Jan Beulich Reviewed-by: Andrew Cooper > --- > Changes in v3: > 1. Coding style fix. > 2. Fix an error code. > 3. Use unsigned int for loop variable. > > Changes in v2: > 1. Adapt to new vNUMA retrieval routine. > 2. Move S

Re: [Xen-devel] [PATCH v5 08/24] libxl: introduce libxl__vnuma_config_check

On Fri, Feb 13, 2015 at 11:06 AM, Wei Liu wrote: > On Fri, Feb 13, 2015 at 10:39:25AM -0500, Elena Ufimtseva wrote: >> On Fri, Feb 13, 2015 at 10:12 AM, Wei Liu wrote: >> > On Fri, Feb 13, 2015 at 02:15:47PM +, Ian Jackson wrote: >> >> Wei Liu writes ("[PATCH v5 08/24] libxl: introduce >> >>

Re: [Xen-devel] [PATCH v5 16/24] libxc: allocate memory with vNUMA information for HVM guest

On 12/02/15 19:44, Wei Liu wrote: > The algorithm is more or less the same as the one used for PV guest. > Libxc gets hold of the mapping of vnode to pnode and size of each vnode > then allocate memory accordingly. > > And then the function returns low memory end, high memory end and mmio > start t

[Xen-devel] [PATCH V5 05/12] tools/tests: Clean-up tools/tests/xen-access

The spin-lock implementation in the xen-access test program is implemented in a fashion that is actually incomplete. The x86 assembly that guarantees that the lock is held by only one thread lacks the "lock;" instruction. However, the spin-lock is not actually necessary in xen-access as it is not

[Xen-devel] [PATCH V5 12/12] xen/vm_event: Add RESUME option to vm_event_op domctl

Thus far mem_access and mem_sharing memops had been able to signal to Xen to start pulling responses off the corresponding rings. In this patch we retire these memops and add them to the option to the vm_event_op domctl. The vm_event_op domctl suboptions are the same for each ring thus we consolid

[Xen-devel] [PATCH V5 03/12] xen/mem_paging: Convert mem_event_op to mem_paging_op

The only use-case of the mem_event_op structure had been in mem_paging, thus renaming the structure mem_paging_op and relocating its associated functions clarifies its actual usage. Signed-off-by: Tamas K Lengyel Acked-by: Tim Deegan Acked-by: Ian Campbell Acked-by: Jan Beulich --- v5: Style f

[Xen-devel] [PATCH V5 00/12] xen: Clean-up of mem_event subsystem

This patch series aims to clean up the mem_event subsystem within Xen. The original use-case for this system was to allow external helper applications running in privileged domains to control various memory operations performed by Xen. Amongs these were paging, sharing and access control. The subsy

[Xen-devel] [PATCH V5 02/12] xen/mem_event: Cleanup mem_event ring names and domctls

The name of one of the mem_event rings still implies it is used only for memory accesses, which is no longer the case. It is also used to deliver various HVM events, thus the name "monitor" is more appropriate in this setting. The mem_event subop definitions are also shortened to be more meaningfu

[Xen-devel] [PATCH V5 07/12] xen: Introduce monitor_op domctl

In preparation for allowing for introspecting ARM and PV domains the old control interface via the hvm_op hypercall is retired. A new control mechanism is introduced via the domctl hypercall: monitor_op. This patch aims to establish a base API on which future applications can build on. Suggested-

[Xen-devel] [PATCH V5 01/12] xen/mem_event: Cleanup of mem_event structures

The public mem_event structures used to communicate with helper applications via shared rings have been used in different settings. However, the variable names within this structure have not reflected this fact, resulting in the reuse of variables to mean different things under different scenarios.

[Xen-devel] [PATCH V5 09/12] xen/vm_event: Decouple vm_event and mem_access.

The vm_event subsystem has been artifically tied to the presence of mem_access. While mem_access does depend on vm_event, vm_event is an entirely independent subsystem that can be used for arbitrary function-offloading to helper apps in domains. This patch removes the dependency that mem_access nee

[Xen-devel] [PATCH V5 11/12] xen/xsm: Split vm_event_op into three separate labels

The XSM label vm_event_op has been used to control the three memops controlling mem_access, mem_paging and mem_sharing. While these systems rely on vm_event, these are not vm_event operations themselves. Thus, in this patch we introduce three separate labels for each of these memops. Signed-off-by

[Xen-devel] [PATCH V5 08/12] xen/vm_event: Check for VM_EVENT_FLAG_DUMMY only in Debug builds

The flag is only used for debugging purposes, thus it should be only checked for in debug builds of Xen. Signed-off-by: Tamas K Lengyel --- xen/arch/x86/mm/mem_sharing.c | 2 ++ xen/arch/x86/mm/p2m.c | 2 ++ xen/common/mem_access.c | 2 ++ 3 files changed, 6 insertions(+) diff --g

[Xen-devel] [PATCH] xen: fix mcelog/stub depend issue in Kconfig

From: Yi Li Fix support mcelog/stub in Kconfig for Xen X86 platform Signed-off-by: Yi Li --- drivers/xen/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index b812462..83ae68a 100644 --- a/drivers/xen/Kconfig +++ b/driv

[Xen-devel] [PATCH V5 06/12] x86/hvm: factor out and rename vm_event related functions

To avoid growing hvm.c these functions can be stored separately. Minor style changes are applied to the logic in the file. Signed-off-by: Tamas K Lengyel Acked-by: Kevin Tian --- v5: Style fixes Fix hvm_event_msr input types to match the incoming variables v4: Style fixes v3: Style fixes and

[Xen-devel] [PATCH V5 04/12] xen: Rename mem_event to vm_event

In this patch we mechanically rename mem_event to vm_event. This patch introduces no logic changes to the code. Using the name vm_event better describes the intended use of this subsystem, which is not limited to memory events. It can be used for off-loading the decision making logic into helper ap

[Xen-devel] [PATCH V5 10/12] xen/vm_event: Relocate memop checks

The memop handler function for paging/sharing responsible for calling XSM doesn't really have anything to do with vm_event, thus in this patch we relocate it into mem_paging_memop and mem_sharing_memop. This has already been the approach in mem_access_memop, so in this patch we just make it consist

Re: [Xen-devel] [PATCH] xen: fix mcelog/stub depend issue in Kconfig

On 13/02/15 16:32, Yi Li wrote: > > From: Yi Li > > Fix support mcelog/stub in Kconfig for Xen X86 platform Is this actually sufficient? I'm fairly sure the Xen MCE driver does not correctly handle the 64-bit ABI that Xen provides and there would need to be some compat translations done. > Si

[Xen-devel] 2015 GSoC Application : Tick

Just a quick note that I filled out the GSoC Mentoring Organisation application today If you have not done so, please read and act on http://lists.xenproject.org/archives/html/xen-devel/2015-02/msg00902.html before Feb

[Xen-devel] [linux-3.16 test] 34493: regressions - FAIL

flight 34493 linux-3.16 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34493/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 15 guest-localmigrate/x10fail REGR. vs. 34167 test-amd64-i386-pair

Re: [Xen-devel] [PATCH V5 01/12] xen/mem_event: Cleanup of mem_event structures

On 13/02/15 16:33, Tamas K Lengyel wrote: > The public mem_event structures used to communicate with helper applications > via > shared rings have been used in different settings. However, the variable names > within this structure have not reflected this fact, resulting in the reuse of > variable

Re: [Xen-devel] [PATCH V5 02/12] xen/mem_event: Cleanup mem_event ring names and domctls

On 13/02/15 16:33, Tamas K Lengyel wrote: > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c > index 339f8fe..5851c66 100644 > --- a/xen/arch/x86/mm/p2m.c > +++ b/xen/arch/x86/mm/p2m.c > @@ -1501,7 +1501,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long > gla, > gfn_unloc

Re: [Xen-devel] [PATCH V5 02/12] xen/mem_event: Cleanup mem_event ring names and domctls

On Fri, Feb 13, 2015 at 6:53 PM, Andrew Cooper wrote: > On 13/02/15 16:33, Tamas K Lengyel wrote: > >> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c >> index 339f8fe..5851c66 100644 >> --- a/xen/arch/x86/mm/p2m.c >> +++ b/xen/arch/x86/mm/p2m.c >> @@ -1501,7 +1501,7 @@ bool_t p2m_mem_a

Re: [Xen-devel] [PATCH V5 01/12] xen/mem_event: Cleanup of mem_event structures

On Fri, Feb 13, 2015 at 6:23 PM, Andrew Cooper wrote: > On 13/02/15 16:33, Tamas K Lengyel wrote: >> The public mem_event structures used to communicate with helper applications >> via >> shared rings have been used in different settings. However, the variable >> names >> within this structure h

Re: [Xen-devel] [PATCH V5 01/12] xen/mem_event: Cleanup of mem_event structures

On 13/02/15 18:03, Tamas K Lengyel wrote: > On Fri, Feb 13, 2015 at 6:23 PM, Andrew Cooper > wrote: >> On 13/02/15 16:33, Tamas K Lengyel wrote: >>> The public mem_event structures used to communicate with helper >>> applications via >>> shared rings have been used in different settings. However,

Re: [Xen-devel] [PATCH V5 01/12] xen/mem_event: Cleanup of mem_event structures

On Fri, Feb 13, 2015 at 7:09 PM, Andrew Cooper wrote: > On 13/02/15 18:03, Tamas K Lengyel wrote: >> On Fri, Feb 13, 2015 at 6:23 PM, Andrew Cooper >> wrote: >>> On 13/02/15 16:33, Tamas K Lengyel wrote: The public mem_event structures used to communicate with helper applications via >

Re: [Xen-devel] [PATCH V5 03/12] xen/mem_paging: Convert mem_event_op to mem_paging_op

On 13/02/15 16:33, Tamas K Lengyel wrote: > The only use-case of the mem_event_op structure had been in mem_paging, > thus renaming the structure mem_paging_op and relocating its associated > functions clarifies its actual usage. > > Signed-off-by: Tamas K Lengyel > Acked-by: Tim Deegan > Acked-b

Re: [Xen-devel] [PATCH V5 03/12] xen/mem_paging: Convert mem_event_op to mem_paging_op

On Fri, Feb 13, 2015 at 7:17 PM, Andrew Cooper wrote: > On 13/02/15 16:33, Tamas K Lengyel wrote: >> The only use-case of the mem_event_op structure had been in mem_paging, >> thus renaming the structure mem_paging_op and relocating its associated >> functions clarifies its actual usage. >> >> Sig

Re: [Xen-devel] [PATCH V5 04/12] xen: Rename mem_event to vm_event

On 13/02/15 16:33, Tamas K Lengyel wrote: > In this patch we mechanically rename mem_event to vm_event. This patch > introduces no logic changes to the code. Using the name vm_event better > describes the intended use of this subsystem, which is not limited to memory > events. It can be used for of

Re: [Xen-devel] [PATCH V5 06/12] x86/hvm: factor out and rename vm_event related functions

On 13/02/15 16:33, Tamas K Lengyel wrote: > To avoid growing hvm.c these functions can be stored separately. Minor style > changes are applied to the logic in the file. > > Signed-off-by: Tamas K Lengyel > Acked-by: Kevin Tian > Reviewed-by: Andrew Cooper __

Re: [Xen-devel] [PATCH v4 2/2] x86, arm, platform, xen, kconfig: add xen defconfig helper

On Tue, Feb 10, 2015 at 05:23:29PM -0800, David Rientjes wrote: > On Tue, 10 Feb 2015, Luis R. Rodriguez wrote: > > > From: "Luis R. Rodriguez" > > > > This lets you build a kernel which can support xen dom0 > > or xen guests by just using: > > > >make xenconfig > > > > on both x86 and arm

[Xen-devel] [PATCH RFC 0/5] pvh: dom0 special memory regions mapping

This patch set introduces xen boot option dom0_iommu_rwmem for special memory regions that are not reported by ACPI as RMRRs and are reserved in e820 map but require iommu mapping RW permissions (per experiment, only R). The problem was discovered in few systems. See discussion: http://lists.xenpro

[Xen-devel] [PATCH RFC 1/5] iommu: need_iommu set early

Set need_iommu for dom0 early so pvh specific functions in construct_dom0 can pass this check. See example in p2m-ept.c ept_set_entry. Signed-off-by: Elena Ufimtseva --- xen/arch/x86/domain_build.c |1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/

[Xen-devel] [PATCH RFC 2/5] p2m: introduce misc type p2m_sys_rw for mmio rw mappings

Introduce p2m type p2m_sys_rw as a preparation for the following patch. It used to provide correct flags for mapping special memory ranges that specified in dom0_iommu_rwmem command line. See comment in the following patch for detailed explanation. Signed-off-by: Elena Ufimtseva --- xen/arch/x86

[Xen-devel] [PATCH RFC 3/5] pvh: add rwmem_ranges to keep mapped special regions

Patch adds rwmem_ranges in arch_hvm_iommu to keep specail regions specified by dom0_iommu_rwmem boot option. These special regions mapped with p2m_sys_rw type introduced in the previous patch. TODO: - specify mapped flag in rwmem_range struct to indicte that actual mapping was successful; Signe

[Xen-devel] [PATCH RFC 4/5] pvh: dom0 add rw mapping for dom0_iommu_rwmem boot opt

Patch adds mapping for memory regions specified by dom0_iommu_rwmem regions. These special regions are not described by ACPI as RMRRs and have special memory type. Condition need_modify_vtd_table to perform iommu mapping is changed in order to take into account pte permission changes applied for th

[Xen-devel] [PATCH RFC 5/5] pvh: dom0 boot option to specify iommu rw ranges

It appears from the experiments that some devices on few systems may attempt to access memory ranges that are not RMRRs regions (and are not reported by ACPI) and are reserved in the host e820 map. These memory addresses appear to be the targets for DMA reads by devices. Presumably, these devices m

[Xen-devel] [linux-3.10 test] 34495: regressions - FAIL

flight 34495 linux-3.10 real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34495/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl5 xen-boot fail REGR. vs. 26303 test-amd64-amd64-xl-qe

Re: [Xen-devel] [PATCH V5 08/12] xen/vm_event: Check for VM_EVENT_FLAG_DUMMY only in Debug builds

On 13/02/15 16:33, Tamas K Lengyel wrote: > The flag is only used for debugging purposes, thus it should be only checked > for in debug builds of Xen. > > Signed-off-by: Tamas K Lengyel What is the purpose of the dummy flag? I would have thought it would be more dangerous to accidentally process

  1   2   >