flight 66454 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66454/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 66415
build-i386-xsm
On Wed, 2015-12-16 at 15:36 +, George Dunlap wrote:
> [Adding Tim, the previous mm maintainer]
>
> On 11/12/15 09:16, Wu, Feng wrote:
> > > > +{
> > > > +void *xsave_addr;
> > > > +unsigned int pkru = 0;
> > > > +bool_t pkru_ad, pkru_wd;
> > > > +
> > > > +bool_t uf = !!(pfec &
This run is configured for baseline tests only.
flight 38531 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38531/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 18 guest-start/de
On 17/12/2015 20:59, Jonathan Creekmore wrote:
> Allow the schedulers to be independently enabled or disabled at
> compile-time instead of just allowing the scheduler to be selected on
> the command line. To match existing behavior, all four schedulers are
> compiled in by default, although the RTD
On 17/12/2015 20:59, Jonathan Creekmore wrote:
> Creates a section to contain scheduler entry pointers that are gathered
> together into an array. This will allow, in a follow-on patch, scheduler
> entries to be automatically gathered together into the array for
> automatic parsing.
>
> CC: Ian Cam
On 17/12/2015 20:59, Jonathan Creekmore wrote:
> Adds a simple macro to place a pointer to a scheduler into an array
> section at compile time. Also, goes ahead and generates the array
> entries with each of the schedulers.
>
> CC: George Dunlap
> CC: Dario Faggioli
> CC: Josh Whitehead
> CC: Ro
On 17/12/2015 20:59, Jonathan Creekmore wrote:
> Instead of having a manually-curated list of schedulers, use the array
> that was auto-generated simply by compiling in the scheduler files as
> the sole source of truth of the available schedulers.
>
> CC: George Dunlap
> CC: Dario Faggioli
> Sign
On Thu, 2015-12-17 at 20:20 -0600, Jonathan Creekmore wrote:
> > On Dec 17, 2015, at 7:35 PM, Dario Faggioli > com> wrote:
> >
> > Fact is, I don't think the phrase "instead of just allowing the
> > scheduler to be selected on the command line." adds much
> > information,
> > and I'd just remove
On 18/12/15 08:21, Han, Huaitong wrote:
> On Wed, 2015-12-16 at 15:36 +, George Dunlap wrote:
>> [Adding Tim, the previous mm maintainer]
>>
>> On 11/12/15 09:16, Wu, Feng wrote:
> +{
> +void *xsave_addr;
> +unsigned int pkru = 0;
> +bool_t pkru_ad, pkru_wd;
> +
Per-cpu read-write locks allow for the fast path read case to have
low overhead by only setting/clearing a per-cpu variable for using
the read lock. The per-cpu read fast path also avoids locked
compare swap operations which can be particularly slow on coherent
multi-socket systems, particularly if
The per domain p2m read lock suffers from significant contention when
performance multi-queue block or network IO due to the parallel
grant map/unmaps/copies occuring on the DomU's p2m.
On multi-socket systems, the contention results in the locked compare swap
operation failing frequently which re
The per domain grant table read lock suffers from significant contention when
performance multi-queue block or network IO due to the parallel
grant map/unmaps/copies occurring on the DomU's grant table.
On multi-socket systems, the contention results in the locked compare swap
operation failing fr
This patch series adds per-cpu reader-writer locks as a generic lock
implementation and then converts the grant table and p2m rwlocks to
use the percpu rwlocks, in order to improve multi-socket host performance.
CPU profiling has revealed the rwlocks themselves suffer from severe cache
line bounci
I didn't spot the percpu rwlock owner ASSERT being the wrong way round.
Please review version 4 of the series.
Sorry for the noise.
On 17/12/15 12:52, Malcolm Crossley wrote:
> This patch series adds per-cpu reader-writer locks as a generic lock
> implementation and then converts the grant table
I didn't spot the percpu rwlock owner ASSERT being the wrong way round.
Please review version 4 of the series.
Sorry for the noise.
On 17/12/15 12:52, Malcolm Crossley wrote:
> Per-cpu read-write locks allow for the fast path read case to have
> low overhead by only setting/clearing a per-cpu var
>>> On 17.12.15 at 21:22, wrote:
> * Left non-MMCFG RO accesses unhandled (we havent't encountered those accesses
> yet with PVH dom0 and it's probably better to fault on them and investigate
> whether they are guest's issues).
I seriously question this being a good approach, since I can't se
On 18/12/15 07:46, Tian, Kevin wrote:
>> From: David Vrabel [mailto:david.vra...@citrix.com]
>> Sent: Thursday, December 17, 2015 11:17 PM
>>
>> This series improves the performance of EPT by further reducing the
>> impact of the translation invalidations (ept_sync_domain()). By:
>>
>> a) Deferring
>>> On 17.12.15 at 21:22, wrote:
> This is provided explicitly in SVM and implicitly in VMX (when neither of
> the three EPT_EFFECTIVE_* bits is set).
>
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Jan Beulich
Retaining full context since you failed to Cc the VMX maintainers,
which I've no d
On 18/12/15 07:53, Tian, Kevin wrote:
>> From: David Vrabel [mailto:david.vra...@citrix.com]
>> Sent: Thursday, December 17, 2015 11:17 PM
>
> [...]
>
>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> index f7c5e4f..cca35f2 100644
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> ++
On 18/12/15 10:18, David Vrabel wrote:
> On 18/12/15 07:53, Tian, Kevin wrote:
>>> From: David Vrabel [mailto:david.vra...@citrix.com]
>>> Sent: Thursday, December 17, 2015 11:17 PM
>>
>> [...]
>>
>>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>>> index f7c5e4f..cca35f2 10
>>> On 17.12.15 at 21:22, wrote:
> Commit 9256f66c1606 ("x86/PCI: intercept all PV Dom0 MMCFG writes")
> added intercepts for writes to RO MMCFG space from PV dom0.
>
> Similar functionality is needed by dom0s in HVM containers (such as
> PVH and, in the future, HVMlite).
>
> Signed-off-by: Bori
On 18/12/15 10:24, George Dunlap wrote:
+ * The invalidate will be done before VMENTER (see
>>>
>>> invalidate -> invalidation?
>>
>> That would be the correct English grammer, yes.
>
> FWIW I think either one is acceptable English grammar.
invalidate is a verb, invalidation is the corre
On Tue, 2015-12-15 at 07:12 -0600, Doug Goldstein wrote:
> The following series is a follow on to the Kconfig conversion patch
> series.
It occurred to me this morning that we probably ought to stash the .config
somewhere on install in such a way that it can be associated with the Xen
binary (i.e.
flight 66458 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66458/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-raw 3 host-install(3) broken pass in 66418
test-armhf-armhf-xl-multivcpu 1
>>> On 18.12.15 at 11:18, wrote:
> On 18/12/15 07:53, Tian, Kevin wrote:
>>> From: David Vrabel [mailto:david.vra...@citrix.com]
>>> Sent: Thursday, December 17, 2015 11:17 PM
>>
>> [...]
>>
>>> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>>> index f7c5e4f..cca35f2 10064
>>> On 17.12.15 at 21:59, wrote:
> Add machinery to allow the schedulers to be individually selectable
> through the Kconfig interface. The first patch in the series sets up
> the Kconfig options for the schedulers and places the appropriate CONFIG_
> options around the scheduler list. The second,
On Thu, 2015-12-17 at 14:59 -0600, Jonathan Creekmore wrote:
> Add machinery to allow the schedulers to be individually selectable
> through the Kconfig interface.
So I don't want to pick on this series or schedulers specifically here, but
instead discuss the general premise of configurability of
>>> On 17.12.15 at 21:59, wrote:
> +extern const struct scheduler *__schedulers_start[], *__schedulers_end[];
> +#define NUM_SCHEDULERS
> (((uintptr_t)__schedulers_end-(uintptr_t)__schedulers_start) \
> +/ sizeof(struct scheduler *))
> +static const struct scheduler **sche
The check needs to be against the xsave header in the area, rather than
Xen's maximum xfeature_mask. A guest might easily have a smaller xcr0
than the maximum Xen is willing to allow, causing the pointer below to
be bogus.
Signed-off-by: Huaitong Han
---
xen/arch/x86/xstate.c | 7 ---
1 file
On 18/12/15 01:35, Dario Faggioli wrote:
> On Thu, 2015-12-17 at 14:59 -0600, Jonathan Creekmore wrote:
>> Allow the schedulers to be independently enabled or disabled at
>> compile-time instead of just allowing the scheduler to be selected on
>> the command line.
>>
> Reading this quickly, that "
On Thu, Dec 17, 2015 at 09:58:38AM -0700, Jan Beulich wrote:
> This eliminates a number of pointless conditionals: Bits 0 and 1 of
> xcomp_bv don't matter anyway, and as long as none of bits 2..62 are
> set, setting bit 63 is pointless too.
>
We should set bit 63 of the xcomp_bv when initializatio
>>> On 18.12.15 at 11:45, wrote:
> How would people feel about a CONFIG_STANDARD_FEATURESET[0] with the
> majority of tweakables depending on !STANDARD_FEATURESET? It would default
> Y with a help text which dissuades normal users from touching it ("Say Y,
> unless you are willing to pick up the p
>>> On 18.12.15 at 09:03, wrote:
> flight 66454 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/66454/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-i3865 xen-build
On 18/12/15 11:45, Ian Campbell wrote:
> On Thu, 2015-12-17 at 14:59 -0600, Jonathan Creekmore wrote:
>> Add machinery to allow the schedulers to be individually selectable
>> through the Kconfig interface.
>
> So I don't want to pick on this series or schedulers specifically here, but
> instead d
>>> On 18.12.15 at 11:53, wrote:
> On Thu, Dec 17, 2015 at 09:58:38AM -0700, Jan Beulich wrote:
>> This eliminates a number of pointless conditionals: Bits 0 and 1 of
>> xcomp_bv don't matter anyway, and as long as none of bits 2..62 are
>> set, setting bit 63 is pointless too.
>>
> We should set
On 18/12/15 10:50, Huaitong Han wrote:
> The check needs to be against the xsave header in the area, rather than
> Xen's maximum xfeature_mask. A guest might easily have a smaller xcr0
> than the maximum Xen is willing to allow, causing the pointer below to
> be bogus.
>
> Signed-off-by: Huaitong H
On Thu, 2015-12-17 at 18:38 +, Ian Jackson wrote:
Continuing purely for my own edification...
> FYI, it's (eliding lots) like this:
>
> sub db_retry ($$$;$$) {
> for (;;) {
> $pre->();
> eval {
> $r= &$body;
> if ($db_retry_stop) {
>
On Fri, 2015-12-18 at 12:08 +0100, Juergen Gross wrote:
> On 18/12/15 11:45, Ian Campbell wrote:
> > On Thu, 2015-12-17 at 14:59 -0600, Jonathan Creekmore wrote:
> > > Add machinery to allow the schedulers to be individually selectable
> > > through the Kconfig interface.
> >
> > So I don't want t
On Fri, 2015-12-18 at 10:52 +, George Dunlap wrote:
> On 18/12/15 01:35, Dario Faggioli wrote:
> > On Thu, 2015-12-17 at 14:59 -0600, Jonathan Creekmore wrote:
> > > Allow the schedulers to be independently enabled or disabled at
> > > compile-time instead of just allowing the scheduler to be
>
flight 66459 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66459/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail
REGR. vs. 65543
test-amd64-i386-
>>> On 18.12.15 at 12:08, wrote:
> What I'd really like to see in the config options are things like:
>
> CONFIG_BIGMEM (instead of doing it via environment variable),
> NR_CPUS, and possibly some other numerical bounds which won't select
> a feature, but might be interesting to change for huge s
On 18/12/15 10:32, Jan Beulich wrote:
On 18.12.15 at 11:18, wrote:
>> On 18/12/15 07:53, Tian, Kevin wrote:
From: David Vrabel [mailto:david.vra...@citrix.com]
Sent: Thursday, December 17, 2015 11:17 PM
>>>
>>> [...]
>>>
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hv
>>> On 18.12.15 at 11:06, wrote:
> @@ -492,6 +494,50 @@ int _rw_is_write_locked(rwlock_t *lock)
> return (lock->lock == RW_WRITE_FLAG); /* writer in critical section? */
> }
>
> +void _percpu_write_lock(percpu_rwlock_t **per_cpudata,
> +percpu_rwlock_t *percpu_rwlock)
> +{
>>> On 18.12.15 at 11:06, wrote:
> --- a/xen/include/xen/grant_table.h
> +++ b/xen/include/xen/grant_table.h
> @@ -51,13 +51,35 @@
> /* The maximum size of a grant table. */
> extern unsigned int max_grant_frames;
>
> +DECLARE_PERCPU_RWLOCK_GLOBAL(grant_rwlock);
> +
> +static inline void grant
On 18/12/15 12:30, Jan Beulich wrote:
On 18.12.15 at 12:08, wrote:
>> What I'd really like to see in the config options are things like:
>>
>> CONFIG_BIGMEM (instead of doing it via environment variable),
>> NR_CPUS, and possibly some other numerical bounds which won't select
>> a feature, bu
flight 66455 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66455/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail REGR. vs. 59254
test-amd64-i386-freeb
At 08:21 + on 18 Dec (1450426907), Han, Huaitong wrote:
> On Wed, 2015-12-16 at 15:36 +, George Dunlap wrote:
> > With your current series, guest_walk_tables() already checks for
> > pkeys
> > being enabled in the guest before checking for them in the
> > pagetables.
> > For shadow mode, th
On 15.12.2015 23:20, Jim Fehlig wrote:
> From: Ian Campbell
>
> xend prior to 4.0 understands vcpus as maxvcpus and vcpu_avail
> as a bit map of which cpus are online (default is all).
>
> xend from 4.0 onwards understands maxvcpus as maxvcpus and
> vcpus as the number which are online (from 0..
On Fri, 2015-12-18 at 04:02 -0700, Jan Beulich wrote:
> Previously build attempts on ix86 resulted in no error, with just
>
> *** Xen x86/32 target no longer supported!
As an aside, could we drop the *** there, or make it something else?
When I look at build failure logs I usually look for the *
Commit fb373a2096dc "cri-getconfig: Break out exec_resetting_sigint."
refactored this functionality, and asserted that cri-getconfig is the
one library which everything includes.
standalone-generate-dump-flight-runvars appears to have been the
exception to that rule.
Signed-off-by: Ian Campbell
Add return codes for pci-detach, pci-attach, pci-asssignable-add, and
pci-assignable-remove.
Returning error codes makes it easier for shell scripts to tell if a
command has failed or succeeded.
NB this violates the CODING_STYLE preference for not initializing the
return-value variable at declara
Return failure when the command failed for more xl commands:
- mem-set
- cd-insert
- pci-*
This makes xl more useful for scripting.
In the case of mem-set, it means first cleaning up
libxl_set_memory_target() to return useful error codes.
Changes in v4:
- Remove block-attach patch
- Split out re
This makes xl more useful in scripts.
The strange thing about this is that the internal cd_insert function
*already* returned something appropriate, and cd-eject was using it,
but cd-insert wasn't.
Also:
* Rework cd_insert to return EXIT_FAILURE and EXIT_SUCCESS rather than
magic constants
* Us
There's no obvious reason for the call to xc_domain_getinfolist -- all
it seems to be doing is checking that the domain exists; but if it
doesn't exist, it will have already failed by this point.
NB that this will change the return value for libxl_set_memory_target:
now it will return 0 on success
Also move the rc -> shell code translation into set_memory_max() to
make the two functions consistent with each other, and with other
similar examples in xl_cmdimpl.c
Change a 'long long' to "int64_t" while we're at it.
Signed-off-by: George Dunlap
---
v4:
- Move rc -> shell return code transla
libxl_set_memory_target seems to have the following return values:
* 1 on failure, if the failure happens because of a xenstore error *or* invalid
target
* -1 if the setmaxmem hypercall
* -errno if the set_pod_target hypercall target fails
* 0 on success
Make it consistently return ERROR_FAIL
>>> On 18.12.15 at 12:50, wrote:
> On Fri, 2015-12-18 at 04:02 -0700, Jan Beulich wrote:
>> Previously build attempts on ix86 resulted in no error, with just
>>
>> *** Xen x86/32 target no longer supported!
>
> As an aside, could we drop the *** there, or make it something else?
>
> When I look
On 18/12/15 10:11, Jan Beulich wrote:
On 17.12.15 at 21:22, wrote:
>> * Left non-MMCFG RO accesses unhandled (we havent't encountered those
>> accesses
>> yet with PVH dom0 and it's probably better to fault on them and investigate
>> whether they are guest's issues).
> I seriously questi
When restarting or shutting down dom0 the xendomains script tries to
stop all other domains. Don't do this for the xenstore domain, as it
might survive a dom0 reboot in the future.
The same applies to xl shutdown --all.
Signed-off-by: Juergen Gross
---
tools/hotplug/Linux/xendomains.in | 17 +++
Additional add some diagnostic messages to the program to have an idea
why it failed.
Signed-off-by: Juergen Gross
Acked-by: Ian Campbell
Acked-by: Daniel De Graaf
---
tools/helpers/init-xenstore-domain.c | 104 ---
1 file changed, 83 insertions(+), 21 deletions
Add libxl_xenstore_domid() to obtain the domain id of the xenstore
domain.
Signed-off-by: Juergen Gross
---
tools/libxl/libxl.c | 24
tools/libxl/libxl.h | 11 +++
2 files changed, 35 insertions(+)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 920
Support the xenstore domain flag for obtaining domain info.
Signed-off-by: Juergen Gross
---
tools/libxc/include/xenctrl.h | 2 +-
tools/libxc/xc_domain.c | 17 +
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/in
Add a parameter to init-xenstore-domain for support of arbitrary
parameters for the xenstore domain.
Signed-off-by: Juergen Gross
Acked-by: Ian Campbell
Acked-by: Daniel De Graaf
---
tools/helpers/init-xenstore-domain.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
di
The program init-xenstore-domain to start a xenstore domain instead
of the xenstored daemon is built, but not installed. Change that.
Move the program to a new tools subdirectory "helpers" to be able to
use libxl in a later patch. Otherwise a dependency loop will be
created.
While moving modify t
Split up tools/helpers/xen-init-dom0.c in order to prepare reusing
generation of the json configuration by init-xenstore-domain.c.
Signed-off-by: Juergen Gross
---
tools/helpers/Makefile| 2 +-
tools/helpers/init-dom-json.c | 59 ++
tools/helpers/init-dom
Move xen-init-dom0 from tools/libxl to tools/helpers, as it is just a
helper program.
Signed-off-by: Juergen Gross
---
tools/helpers/Makefile | 10 ++
tools/{libxl => helpers}/xen-init-dom0.c | 0
tools/libxl/Makefile | 14 +++---
3 files ch
Xen supports to run xenstore in a dedicated domain. It is, however, a
setup which isn't easy to configure. Today flask is required for full
functionality and the resulting xenstore domain is not configurable in
the same way as the xenstore daemon.
This patch series enables running a xenstore domai
init-xenstore-domain takes only positional parameters today. Change
this to a more flexible parameter syntax allowing to specify additional
options or to omit some.
Today the supported usage is:
init-xenstore-domain
[]
Modify this to:
init-xenstore-domain --kernel
When creating a xenstore domain via init-xenstore-domain destroy it
in case of an error occurred after calling xc_domain_create().
Signed-off-by: Juergen Gross
Acked-by: Daniel De Graaf
---
tools/helpers/init-xenstore-domain.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
Create the xenstore domain with the xs_domain flag specified. This
enables us to test whether such a domain is already running before
we create it. As there ought to be only one xenstore in the system
we don't need to start another one.
Signed-off-by: Juergen Gross
---
tools/helpers/init-xenstor
After starting the xenstore domain write the basic data (domid, name
and memory values) to the xenstore. This makes the domain appear
correctly in xl list. Create a stub json object in order to make e.g.
xl list -l happy.
Add a new option to init-xenstore-domain to be able to specify the
domain's
In order to be able to have full support of a xenstore domain in Xen
add a "Xenstore-domain" flag to the hypervisor. This flag must be
specified at domain creation time and is returned by
XEN_DOMCTL_getdomaininfo.
It will allow the domain to retrieve domain information by issuing the
XEN_DOMCTL_ge
On 18/12/15 11:02, Jan Beulich wrote:
On 18.12.15 at 09:03, wrote:
>> flight 66454 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/66454/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> buil
Hello,
I am facing problem during mini-os boot-up. The execution breaks while checking
for fdt_check_header while calling fdt32_to_cpu. I think it is not able to use
the address of the dtb provided during arch_init.
The address i can see is 0x0840.
(d3) Virtual -> physical offset = 3fc0
On 18/12/15 13:14, Juergen Gross wrote:
> In order to be able to have full support of a xenstore domain in Xen
> add a "Xenstore-domain" flag to the hypervisor. This flag must be
> specified at domain creation time and is returned by
> XEN_DOMCTL_getdomaininfo.
>
> It will allow the domain to retri
On Fri, 2015-12-18 at 13:17 +, Misra Pankaj Kumar (RBEI/EEA2) wrote:
> Hello,
I've just replied to this message on minios-devel.
While cross posting might be appropriate in this case, please do it in a
single message so we don't end up with two threads.
Ian.
>>> On 18.12.15 at 14:19, wrote:
> However, it is also wrong for OSSTest to be attempting to build a 32bit
> hypervisor on any branch since 4.3. It seems to me that there is a bug
> there as well.
>
> Independently of not falling over a missing defconfig, the following code
>
> ifneq ($(XEN_TAR
On Fri, 2015-12-18 at 13:19 +, Andrew Cooper wrote:
> However, it is also wrong for OSSTest to be attempting to build a 32bit
> hypervisor on any branch since 4.3. It seems to me that there is a bug
> there as well.
It is doing a build because it wants the 32 bit tools and it just does a
mak
This series improves the performance of EPT by further reducing the
impact of the translation invalidations (ept_sync_domain()). By:
a) Deferring invalidations until the p2m write lock is released.
Prior to this change a 16 VCPU guest could not be successfully
migrated on an (admittedly slow) 160
If a guest allocates a page and the tlbflush_timestamp on the page
indicates that a TLB flush of the previous owner is required, only the
linear and combined mappings are invalidated. The guest-physical
mappings are not invalidated.
This is currently safe because the EPT code ensures that the
gue
Holding the p2m lock while calling ept_sync_domain() is very expensive
since it does a on_selected_cpus() call. IPIs on many socket machines
can be very slows and on_selected_cpus() is serialized.
It is safe to defer the invalidate until the p2m lock is released
except for two cases:
1. When fre
On 18/12/15 13:14, Juergen Gross wrote:
> Add libxl_xenstore_domid() to obtain the domain id of the xenstore
> domain.
>
> Signed-off-by: Juergen Gross
What are the expected semantics here? Would you expect it to return
domid 0 for a traditional setup, or are you wanting to use it as a "does
a xe
On 12/18/2015 08:02 AM, Andrew Cooper wrote:
On 18/12/15 10:11, Jan Beulich wrote:
On 17.12.15 at 21:22, wrote:
* Left non-MMCFG RO accesses unhandled (we havent't encountered those accesses
yet with PVH dom0 and it's probably better to fault on them and investigate
whether they are gues
flight 38533 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38533/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-jessie-netboot-pvgrub 10 guest-startfail like 38494
Tests which did
On 12/18/15 5:02 AM, Jan Beulich wrote:
On 18.12.15 at 09:03, wrote:
>> flight 66454 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/66454/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests which could not be run:
>> bu
This series adds the qrwlocks from Linux. These are fair; under
contention both readers and writers will be queued and obtain the lock
in FIFO order (due to the fairness of the internal ticket lock).
The implementation is all in C and thus architecture independent.
Compared to the Linux implemen
From: Konrad Rzeszutek Wilk
Our 'struct domain' has when lock profiling is enabled is bigger than
one page.
We can't use vmap nor vzalloc as both of those stash the
physical address in struct page which makes the assumptions
in 'arch_init_memory' trip over ASSERTs.
Signed-off-by: Konrad Rzeszut
From: Jennifer Herbert
The current rwlocks are write-biased and unfair. This allows writers
to starve readers in situations where there are many writers (e.g.,
p2m type changes from log dirty updates during domain save).
Introduce queued read-write locks which use a fair spinlock (a ticket
lock
atomic_compareandswap() used atomic_t as the new, old and returned
values which is less convinient than using just int.
Signed-off-by: David Vrabel
---
xen/common/domain.c | 5 +
xen/include/asm-arm/atomic.h | 8
xen/include/asm-x86/atomic.h | 8
xen/include/xen
From: Jennifer Herbert
Reduce the size of struct lock_debug so increases in other lock
structures don't increase the size of struct domain too much.
Signed-off-by: Jennifer Herbert
Signed-off-by: David Vrabel
---
xen/common/spinlock.c | 2 +-
xen/include/xen/spinlock.h | 2 +-
2 files ch
On 18/12/15 14:53, Andrew Cooper wrote:
> On 18/12/15 13:14, Juergen Gross wrote:
>> Add libxl_xenstore_domid() to obtain the domain id of the xenstore
>> domain.
>>
>> Signed-off-by: Juergen Gross
>
> What are the expected semantics here? Would you expect it to return
> domid 0 for a traditional
On 18/12/15 13:33, Ian Campbell wrote:
>> However, it is also wrong for OSSTest to be attempting to build a 32bit
>> > hypervisor on any branch since 4.3. It seems to me that there is a bug
>> > there as well.
> It is doing a build because it wants the 32 bit tools and it just does a
> make dist.
>>> On 18.12.15 at 14:53, wrote:
> On 12/18/2015 08:02 AM, Andrew Cooper wrote:
>> On 18/12/15 10:11, Jan Beulich wrote:
>> On 17.12.15 at 21:22, wrote:
* Left non-MMCFG RO accesses unhandled (we havent't encountered those
> accesses
yet with PVH dom0 and it's probably better to
On 12/18/15 4:30 AM, Ian Campbell wrote:
> On Tue, 2015-12-15 at 07:12 -0600, Doug Goldstein wrote:
>> The following series is a follow on to the Kconfig conversion patch
>> series.
>
> It occurred to me this morning that we probably ought to stash the .config
> somewhere on install in such a way
>>> On 18.12.15 at 15:15, wrote:
> On 18/12/15 13:33, Ian Campbell wrote:
>>> However, it is also wrong for OSSTest to be attempting to build a 32bit
>>> > hypervisor on any branch since 4.3. It seems to me that there is a bug
>>> > there as well.
>> It is doing a build because it wants the 32 bi
On Fri, 2015-12-18 at 14:15 +, Andrew Cooper wrote:
> On 18/12/15 13:33, Ian Campbell wrote:
> > > However, it is also wrong for OSSTest to be attempting to build a
> > > 32bit
> > > > hypervisor on any branch since 4.3. It seems to me that there is a
> > > > bug
> > > > there as well.
> > It
On 12/18/2015 09:16 AM, Jan Beulich wrote:
On 18.12.15 at 14:53, wrote:
On 12/18/2015 08:02 AM, Andrew Cooper wrote:
On 18/12/15 10:11, Jan Beulich wrote:
On 17.12.15 at 21:22, wrote:
* Left non-MMCFG RO accesses unhandled (we havent't encountered those
accesses
yet with PVH dom0 and
xl list is currently limited to 1024 domains. Remove the limit.
Signed-off-by: Juergen Gross
---
tools/libxl/libxl.c | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9207621..83e37a9 100644
Ian Campbell writes ("[PATCH OSSTEST] standalone-generate-dump-flight-runvars:
include cri-getconfig"):
> Commit fb373a2096dc "cri-getconfig: Break out exec_resetting_sigint."
> refactored this functionality, and asserted that cri-getconfig is the
> one library which everything includes.
>
> stan
>>> On 18.12.15 at 15:30, wrote:
> On 12/18/2015 09:16 AM, Jan Beulich wrote:
> On 18.12.15 at 14:53, wrote:
>>> On 12/18/2015 08:02 AM, Andrew Cooper wrote:
On 18/12/15 10:11, Jan Beulich wrote:
On 17.12.15 at 21:22, wrote:
>> * Left non-MMCFG RO accesses unhandled (we hav
1 - 100 of 202 matches
Mail list logo
