flight 64185 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64185/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 0c9a522f28772049ae37c85b8ae589a98d2d3b81
baseline version:
ovmf d6cc284e6f9d2e303a81b3ee8a167eb7252
flight 64178 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64178/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken REGR. vs. 62648
build-armhf-pvops
flight 64179 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64179/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 63340
build-armhf-libvirt
On 11/13/2015 10:00 AM, Dario Faggioli wrote:
> Hello,
>
> The Xen Project's automated test suite is failing at running its
> libvirt tests for a few time, like this:
>
> On Wed, 2015-11-04 at 09:04 +, osstest service owner wrote:
>> flight 63528 libvirt real [real]
>> http://logs.test-lab.xenp
Split per ring information to an new structure "xen_blkif_ring", so that one vbd
device can be associated with one or more rings/hardware queues.
Introduce 'pers_gnts_lock' to protect the pool of persistent grants since we
may have multi backend threads.
This patch is a preparation for supporting
Preparatory patch for multiple hardware queues (rings). The number of
rings is unconditionally set to 1, larger number will be enabled in next
patch("xen/blkback: get the number of hardware queues/rings from blkfront") so
as to make every single patch small and readable.
Signed-off-by: Arianna Ava
Make persistent grants per-queue/ring instead of per-device, so that we can
drop the 'dev_lock' and get better scalability.
Test was done based on null_blk driver:
dom0: v4.2-rc8 16vcpus 10GB "modprobe null_blk"
domu: v4.2-rc8 16vcpus 10GB
[test]
rw=read
direct=1
ioengine=libaio
bs=4k
time_based
Split per ring information to an new structure "blkfront_ring_info".
A ring is the representation of a hardware queue, every vbd device can associate
with one or more rings depending on how many hardware queues/rings to be used.
This patch is a preparation for supporting real multi hardware queue
Backend advertises "multi-queue-max-queues" to front, also get the negotiated
number from "multi-queue-num-queues" written by blkfront.
Signed-off-by: Bob Liu
---
drivers/block/xen-blkback/blkback.c | 12
drivers/block/xen-blkback/common.h |1 +
drivers/block/xen-blkback/xenb
After commit "xen/blkfront: separate per ring information out of device
info", per-ring data is protected by a per-device lock('io_lock').
This is not a good way and will effect the scalability, so introduces a
per-ring lock('ring_lock').
The old 'io_lock' is renamed to 'dev_lock' which protects
Make pool of persistent grants and free pages per-queue/ring instead of
per-device to get better scalability.
Test was done based on null_blk driver:
dom0: v4.2-rc8 16vcpus 10GB "modprobe null_blk"
domu: v4.2-rc8 16vcpus 10GB
[test]
rw=read
direct=1
ioengine=libaio
bs=4k
time_based
runtime=30
fil
Preparatory patch for multiple hardware queues (rings). The number of
rings is unconditionally set to 1, larger number will be enabled in next
patch("xen/blkfront: negotiate number of queues/rings to be used with backend")
so as to make every single patch small and readable.
Signed-off-by: Bob Liu
Note: These patches were based on original work of Arianna's internship for
GNOME's Outreach Program for Women.
After using blk-mq api, a guest has more than one(nr_vpus) software request
queues associated with each block front. These queues can be mapped over several
rings(hardware queues) to the
Document the multi-queue/ring feature in terms of XenStore keys to be written by
the backend and by the frontend.
Signed-off-by: Bob Liu
---
v2:
Add descriptions together with multi-page ring buffer.
---
include/xen/interface/io/blkif.h | 48 ++
1 file chang
The max number of hardware queues for xen/blkfront is set by parameter
'max_queues'(default 4), while it is also capped by the max value that the
xen/blkback exposes through XenStore key 'multi-queue-max-queues'.
The negotiated number is the smaller one and would be written back to xenstore
as "mu
flight 64177 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64177/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-build fail REGR. vs. 64095
build-i386
This run is configured for baseline tests only.
flight 38275 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38275/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 3 host-install
flight 64176 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64176/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 21 guest-migrate/src_host/dst_host fail REGR. vs.
63212
Tests whic
On 11/13/2015 06:26 PM, Andy Lutomirski wrote:
On Fri, Nov 13, 2015 at 3:18 PM, Boris Ostrovsky
wrote:
After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack
frame that is passed to xen_sysexit is no lon
flight 64165 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64165/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684
test-amd64
Am 13.11.15 um 11:09 schrieb Andrew Cooper:
On 13/11/15 07:25, Jan Beulich wrote:
On 13.11.15 at 00:00, wrote:
Am 12.11.15 um 17:43 schrieb Andrew Cooper:
On 12/11/15 14:29, Atom2 wrote:
Hi Andrew,
thanks for your reply. Answers are inline further down.
Am 12.11.15 um 14:01 schrieb Andrew C
On 03/11/15 13:15, Ross Lagerwall wrote:
From: Konrad Rzeszutek Wilk
The implementation does not actually do any patching.
It just adds the framework for doing the hypercalls,
keeping track of ELF payloads, and the basic operations:
- query which payloads exist,
- query for specific payloa
On Fri, Nov 13, 2015 at 3:18 PM, Boris Ostrovsky
wrote:
> After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
> ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack
> frame that is passed to xen_sysexit is no longer a "standard" one (i.e.
> it's not pt_regs)
flight 64158 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64158/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3 16 guest-localmigrate/x10 fail in 64056
REGR. vs. 63532
Tests
After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack
frame that is passed to xen_sysexit is no longer a "standard" one (i.e.
it's not pt_regs).
We need to adjust it so that subsequent xen_iret can use it.
On 11/13/15 4:31 PM, Doug Goldstein wrote:
> On 11/13/15 5:41 AM, Julien Grall wrote:
>> Hi Doug,
>>
>> On 12/11/15 22:54, Doug Goldstein wrote:
>>> The following series is a follow on to the Kconfig conversion patch series.
>>> There are still more components to convert however this is the bare mi
On 11/13/15 5:41 AM, Julien Grall wrote:
> Hi Doug,
>
> On 12/11/15 22:54, Doug Goldstein wrote:
>> The following series is a follow on to the Kconfig conversion patch series.
>> There are still more components to convert however this is the bare minimal
>> to get everything working and get the op
Prior to this patch, libxl events were delivered to libvirt via
the libxlDomainEventHandler callback registered with libxl.
Documenation in $xensrc/tools/libxl/libxl_event.h states that the
callback "may occur on any thread in which the application calls
libxl". This can result in deadlock since ma
flight 64153 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64153/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 5 xen-build fail REGR. vs. 63449
build-i386-prev
On 13/11/15 10:02, Ian Campbell wrote:
On Wed, 2015-11-11 at 15:03 +, Ian Jackson wrote:
Ian Campbell writes ("[PATCH XEN v5 07/23] tools: Refactor
/dev/xen/gnt{dev,shr} wrappers into libxengnttab."):
libxengnttab will provide a stable API and ABI for accessing the
grant table devices.
The
flight 64150 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64150/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-multivcpu 15 guest-start.2 fail in 64054 pass in 64150
test-amd64-i386-xl-raw 10
When using EPT, type changes are done with the following steps:
1. Set entry as invalid (misconfigured) by settings a reserved memory
type.
2. Flush all EPT and combined translations (ept_sync_domain()).
3. Fixup misconfigured entries as required (on EPT_MISCONFIG vmexits or
when explicitly sett
This RFC series improves the performance of EPT by reducing the impact
of the translation invalidations (ept_sync_domain()). Two approaches
are used:
a) Removing unnecessary invalidations after fixing misconfigured
entries (after a type change).
b) Deferring invalidations until the p2m write
If a page is freed without translations being invalidated, and the page is
subsequently allocated to another domain, a guest with a cached
translation will still be able to access the page.
Currently translations are invalidated before releasing the page ref, but
while still holding the mm locks.
From: David Vrabel
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.
Defer the invalidate until the p2m lock is released. Since the processor
may c
(CC David, Boris and Konrad)
On 13/11/15 18:10, Stefano Stabellini wrote:
> On Fri, 13 Nov 2015, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 12/11/15 17:30, Stefano Stabellini wrote:
>>> Signed-off-by: Stefano Stabellini
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - rename dom0_op to platform_op
>>> -
On Fri, 13 Nov 2015, Julien Grall wrote:
> Hi Stefano,
>
> On 12/11/15 17:30, Stefano Stabellini wrote:
> > Signed-off-by: Stefano Stabellini
> >
> > ---
> >
> > Changes in v2:
> > - rename dom0_op to platform_op
> > ---
> > arch/arm/include/asm/xen/hypercall.h |2 ++
> > arch/arm/xen/enli
flight 64221 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64221/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
On 13/11/15 17:41, Jan Beulich wrote:
On 13.11.15 at 17:26, wrote:
>> On 13/11/15 15:44, Jan Beulich wrote:
>>> setup_IO_APIC_irqs() runs before APs get brought up, so using
>>> desc->arch.cpu_mask as best risks it being either empty or having bits
>>> for CPUs other than the BP set. Just use
On Fri, 13 Nov 2015, Roger Pau Monne wrote:
> Due to the addition of HVMlite and the requirement to always provide a valid
> xc_domain_configuration_t, xc_domain_create now always takes an arch domain
> config, which can be NULL in order to mimic previous behaviour.
>
> Add a small stub called xen_
>>> On 13.11.15 at 17:26, wrote:
> On 13/11/15 15:44, Jan Beulich wrote:
>> setup_IO_APIC_irqs() runs before APs get brought up, so using
>> desc->arch.cpu_mask as best risks it being either empty or having bits
>> for CPUs other than the BP set. Just use the APIC ID of the only
>> online CPU dire
On 13/11/15 15:41, Jan Beulich wrote:
> ..., i.e. namely that of a PCI serial card with an IRQ above the
> legacy range. This had got broken by the switch to cpumask_any() in
> cpu_mask_to_apicid_phys(). Fix this by allowing all CPUs for that IRQ
> (via setup_vector_irq() properly updating a bootin
Hello,
I worked this summer as an intern under Julien Grall and Wei Liu.
My project was to develop a prototype/proof of concept xen front/back
end for the 9p file system. I mostly hacked the virtio 9p system.
This project was not complete, at the end of the summer. Julien
said that
On Fri, 2015-11-13 at 18:16 +0100, Roger Pau Monné wrote:
> El 13/11/15 a les 17.57, Ian Campbell ha escrit:
> > On Fri, 2015-11-13 at 15:16 +, Ian Campbell wrote:
> > >
> > > On FreeBSD hypercall->retval is in the XEN_ERRNO_* space. But I think
> > > we
> > > probably want to map onto the Fre
El 13/11/15 a les 17.57, Ian Campbell ha escrit:
> On Fri, 2015-11-13 at 15:16 +, Ian Campbell wrote:
>>
>> On FreeBSD hypercall->retval is in the XEN_ERRNO_* space. But I think we
>> probably want to map onto the FreeBSD ERRNO space, IIRC we decided on this
>> approach, rather than converting
In fact, with 2 cpupools, one (the default) Credit and
one Credit2 (with at least 1 pCPU in the latter), trying
a (e.g., ACPI S3) suspend/resume crashes like this:
(XEN) [ 150.587779] [ Xen-4.7-unstable x86_64 debug=y Not tainted ]
(XEN) [ 150.587783] CPU:6
(XEN) [ 150.587786] RI
Hello,
The Xen Project's automated test suite is failing at running its
libvirt tests for a few time, like this:
On Wed, 2015-11-04 at 09:04 +, osstest service owner wrote:
> flight 63528 libvirt real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/63528/
>
> Regressions :-(
>
> T
On Fri, 2015-11-13 at 15:16 +, Ian Campbell wrote:
>
> On FreeBSD hypercall->retval is in the XEN_ERRNO_* space. But I think we
> probably want to map onto the FreeBSD ERRNO space, IIRC we decided on this
> approach, rather than converting all our callers to the XEN_ERRNO_* space,
> in a previ
On Fri, 2015-11-13 at 15:16 +, Ian Campbell wrote:
>
> If we are going to standardise on one of those then given we've gone for
> -1/errno in most other places and it's the "normal" way to do things I
> think we should do the same here and the freebsd driver in libxencall
> should set errno.
>
On 11/12/2015 07:40 PM, Jim Fehlig wrote:
> The fix for XSA-142 is quite a big hammer, rejecting readonly
> disk configuration even when the requested backend is known to
> support readonly. While it is true that qemu doesn't support
> readonly for emulated IDE or AHCI disks
>
> $ /usr/lib/xen/bin/
Due to the addition of HVMlite and the requirement to always provide a valid
xc_domain_configuration_t, xc_domain_create now always takes an arch domain
config, which can be NULL in order to mimic previous behaviour.
Add a small stub called xen_domain_create that encapsulates the correct call
to x
Paul Durrant writes ("RE: [PATCH v3 4/4] docs: Document xenstore paths for
domain network address information"):
> [Ian:]
> > The primary (virtual hardware) VIF MAC address is already recorded by
> > the toolstack in the PV protocol backend directory.
> >
> > What is this for ?
>
> The frontend
Paul Durrant writes ("RE: [Xen-devel] [PATCH v3 0/4] docs: Document xenstore
paths"):
> [Ian:]
> > And the documents themselves should then clearly state what the
> > behaviour should be on the part of a toolstack which finds the
> > information missing, or set to a particular values.
>
> Yes, I
On 13/11/15 15:44, Jan Beulich wrote:
> setup_IO_APIC_irqs() runs before APs get brought up, so using
> desc->arch.cpu_mask as best risks it being either empty or having bits
> for CPUs other than the BP set. Just use the APIC ID of the only
> online CPU directly. Replace a stray hard_smp_processor
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 13 November 2015 16:20
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org
> Subject: RE: [Xen-devel] [PATCH v3 0/4] docs: Document xenstore paths
>
> Paul Durrant writes ("RE: [Xen-devel] [PATCH v3 0/4
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 13 November 2015 16:18
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Ian Campbell; Jan Beulich; Keir (Xen.org);
> Tim (Xen.org)
> Subject: Re: [PATCH v3 4/4] docs: Document xenstore paths for doma
Paul Durrant writes ("RE: [Xen-devel] [PATCH v3 2/4] docs: Document a xenstore
path for PV driver version information..."):
> [Ian J:]
> > If it is to be used for bug workaround, it definitely needs to be more
> > structured.
>
> No, that's not the intention. The intention is that the inform
On 09/11/15 12:00, Ian Campbell wrote:
> Signed-off-by: Ian Campbell
> Acked-by: Wei Liu
I agree with the sentiment, but the error message refer to the
libxencall entry API, so a developer can match it back to the call in
their code.
~Andrew
> ---
> tools/libs/call/linux.c | 4 ++--
> 1 file
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 13 November 2015 16:12
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Keir (Xen.org); Ian Campbell; Tim
> (Xen.org); Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v3 2/4] docs: Document a xenstore
Paul Durrant writes ("[PATCH v3 4/4] docs: Document xenstore paths for domain
network address information"):
> + ~/attr/vif/$DEVID/name = STRING [w]
You need to explicitly state what this information is to be used for.
This "name" is presumably useful for humans in the management UI ?
You ne
On 13/11/15 16:16, Andrew Cooper wrote:
> On 09/11/15 12:00, Ian Campbell wrote:
>> diff --git a/tools/libs/foreignmemory/linux.c
>> b/tools/libs/foreignmemory/linux.c
>> index 01cd42e..86a5a97 100644
>> --- a/tools/libs/foreignmemory/linux.c
>> +++ b/tools/libs/foreignmemory/linux.c
>> @@ -276,6
On 09/11/15 12:00, Ian Campbell wrote:
> diff --git a/tools/libs/foreignmemory/linux.c
> b/tools/libs/foreignmemory/linux.c
> index 01cd42e..86a5a97 100644
> --- a/tools/libs/foreignmemory/linux.c
> +++ b/tools/libs/foreignmemory/linux.c
> @@ -276,6 +276,12 @@ void *xenforeignmemory_map(xenforeign
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 13 November 2015 16:10
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v3 0/4] docs: Document xenstore paths
>
> Paul Durrant writes ("[Xen-devel] [PATCH v3 0/4] do
Paul Durrant writes ("[Xen-devel] [PATCH v3 2/4] docs: Document a xenstore path
for PV driver version information..."):
> diff --git a/docs/misc/xenstore-paths.markdown
> b/docs/misc/xenstore-paths.markdown
> index 71dfda2..cae5115 100644
> --- a/docs/misc/xenstore-paths.markdown
> +++ b/docs/mis
Paul Durrant writes ("[Xen-devel] [PATCH v3 0/4] docs: Document xenstore
paths"):
> Patch #1 documents paths, some already in used by XenServer, which can be
> used by guests to advertise contol capabilities.
Thanks for these patches. I am pleased to see what for upstream Xen
are new facilities
On 13/11/15 15:46, Jan Beulich wrote:
> ... and use what it aliased to directly.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 13/11/15 15:44, Stefano Stabellini wrote:
> On Mon, 9 Nov 2015, Julien Grall wrote:
>> -static struct vcpu *vgic_v3_get_target_vcpu(struct vcpu *v,
unsigned int irq)
>> -{
>> -struct vcpu *v_target;
>> -struct vgic_irq_rank *rank = vgic_rank_irq(v, irq);
>> +#define NR_BYTES_PER_IROUTER
On 09/11/15 12:00, Ian Campbell wrote:
> diff --git a/tools/libs/call/linux.c b/tools/libs/call/linux.c
> new file mode 100644
> index 000..906ca7e
> --- /dev/null
> +++ b/tools/libs/call/linux.c
> @@ -0,0 +1,132 @@
> +/*
> + * This library is free software; you can redistribute it and/or
> + *
... and use what it aliased to directly.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -162,13 +162,13 @@ static inline u32 _phys_pkg_id(u32 cpuid
/*
* cpuid returns the value latched in the HW at reset, not the APIC ID
* register's value. Fo
On Mon, 9 Nov 2015, Julien Grall wrote:
> Xen is currently directly storing the value of GICD_ITARGETSR register
> (for GICv2) and GICD_IROUTER (for GICv3) in the rank. This makes the
> emulation of the registers access very simple but makes the code to get
> the target vCPU for a given vIRQ more c
setup_IO_APIC_irqs() runs before APs get brought up, so using
desc->arch.cpu_mask as best risks it being either empty or having bits
for CPUs other than the BP set. Just use the APIC ID of the only
online CPU directly. Replace a stray hard_smp_processor_id() at once.
Signed-off-by: Jan Beulich
-
..., i.e. namely that of a PCI serial card with an IRQ above the
legacy range. This had got broken by the switch to cpumask_any() in
cpu_mask_to_apicid_phys(). Fix this by allowing all CPUs for that IRQ
(via setup_vector_irq() properly updating a booting CPU's vector_irq[],
thus avoiding "No irq ha
On 13/11/15 15:05, Stefano Stabellini wrote:
> On Fri, 13 Nov 2015, Julien Grall wrote:
>> On 13/11/15 14:37, Stefano Stabellini wrote:
>>> On Mon, 9 Nov 2015, Julien Grall wrote:
+for ( i = 0; i < NR_TARGETS_PER_ITARGETSR; i++, offset++, virq++ )
>>>
>>> offset is not needed in the loop
>
On Fri, 2015-11-13 at 15:05 +, Andrew Cooper wrote:
> On 09/11/15 12:00, Ian Campbell wrote:
> > diff --git a/tools/ocaml/Makefile.rules b/tools/ocaml/Makefile.rules
> > index 1796060..45e71f2 100644
> > --- a/tools/ocaml/Makefile.rules
> > +++ b/tools/ocaml/Makefile.rules
> > @@ -1,18 +1,18 @@
On 09/11/15 12:00, Ian Campbell wrote:
> diff --git a/tools/libs/call/include/xencall.h
> b/tools/libs/call/include/xencall.h
> new file mode 100644
> index 000..a0b3591
> --- /dev/null
> +++ b/tools/libs/call/include/xencall.h
> @@ -0,0 +1,84 @@
> +/*
> + * This library is free software; you
Ian Campbell writes ("Re: [PATCH XEN v5 13/23] tools: Refactor foreign memory
mapping into libxenforeignmemory"):
> On Wed, 2015-11-11 at 15:13 +, Ian Jackson wrote:
> Are you suggesting:
>
> void *xenforeignmemory_map(xenforeignmemory_handle *fmem, uint32_t dom,
>
On Wed, 2015-11-11 at 15:13 +, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH XEN v5 13/23] tools: Refactor foreign memory
> mapping into libxenforeignmemory"):
> > libxenforeignmemory will provide a stable API and ABI for mapping
> > foreign domain memory (subject to appropriate privileges)
On 13/11/15 11:08, Dario Faggioli wrote:
> In fact, with 2 cpupools, one (the default) Credit and
> one Credit2 (with at least 1 pCPU in the latter), trying
> a (e.g., ACPI S3) suspend/resume crashes like this:
>
> (XEN) [ 150.587779] [ Xen-4.7-unstable x86_64 debug=y Not tainted
> ]
On Wed, 2015-11-11 at 15:31 +, Wei Liu wrote:
> On Wed, Nov 11, 2015 at 03:08:13PM +, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH XEN v5 09/23] tools: Refactor hypercall
> > calling wrappers into libxencall."):
> > > libxencall will provide a stable API and ABI for calling hypercall
On Wed, 2015-11-11 at 15:08 +, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH XEN v5 09/23] tools: Refactor hypercall
> calling wrappers into libxencall."):
> > libxencall will provide a stable API and ABI for calling hypercalls
> > (although those hypercalls themselves may not have a stable
On Fri, 13 Nov 2015, Julien Grall wrote:
> On 13/11/15 14:37, Stefano Stabellini wrote:
> > On Mon, 9 Nov 2015, Julien Grall wrote:
> >> +#define NR_TARGETS_PER_ITARGETSR4U
> >> +#define NR_BITS_PER_TARGET (32U / NR_TARGETS_PER_ITARGETSR)
> >> +
> >> +/*
> >> + * Store an ITARGETSR register. T
On 09/11/15 12:00, Ian Campbell wrote:
> diff --git a/tools/ocaml/Makefile.rules b/tools/ocaml/Makefile.rules
> index 1796060..45e71f2 100644
> --- a/tools/ocaml/Makefile.rules
> +++ b/tools/ocaml/Makefile.rules
> @@ -1,18 +1,18 @@
> -ifdef V
> - ifeq ("$(origin V)", "command line")
> -BUILD_V
On Wed, 2015-11-11 at 15:03 +, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH XEN v5 07/23] tools: Refactor
> /dev/xen/gnt{dev,shr} wrappers into libxengnttab."):
> > libxengnttab will provide a stable API and ABI for accessing the
> > grant table devices.
> >
> > The functions are moved in
On 13/11/15 14:37, Stefano Stabellini wrote:
> On Mon, 9 Nov 2015, Julien Grall wrote:
>> +#define NR_TARGETS_PER_ITARGETSR4U
>> +#define NR_BITS_PER_TARGET (32U / NR_TARGETS_PER_ITARGETSR)
>> +
>> +/*
>> + * Store an ITARGETSR register. This function only deals with ITARGETSR8
>> + * and onwa
On Fri, 2015-11-13 at 09:42 -0500, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 12, 2015 at 04:40:06PM +, Ian Campbell wrote:
> > On Fri, 2015-07-10 at 14:57 -0400, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Jul 10, 2015 at 02:37:46PM -0400, Konrad Rzeszutek Wilk
> > > wrote:
> > > > When Xen mig
>>> On 13.11.15 at 15:25, wrote:
> So, all in all, the patch (maybe after reordering the free-s?) remains
> the best way forward, IMO. It's possible that, in future, we'' be able
> to improve things toward the 'no allocs in resume path' goal, and I'll
> keep an eye out for that, when touching rela
On Thu, Nov 12, 2015 at 04:40:06PM +, Ian Campbell wrote:
> On Fri, 2015-07-10 at 14:57 -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, Jul 10, 2015 at 02:37:46PM -0400, Konrad Rzeszutek Wilk wrote:
> > > When Xen migrates an HVM guest, by default its shared_info can
> > > only hold up to 32 CP
On Mon, 9 Nov 2015, Julien Grall wrote:
> The current implementation ignores the whole write if one of the field is
> 0. Although, based on the spec (4.3.12 IHI 0048B.b), 0 is a valid value
> when:
> - The interrupt is not wired in the distributor. From the Xen
> point of view, it means tha
On Fri, 2015-11-13 at 05:52 -0700, Jan Beulich wrote:
>>> On 13.11.15 at 13:30, wrote:
> > cpu_schedule_up() allocates, with the alloc_pdata hook, stuff that
> > was
> > freed by cpu_schedule_down (with the free_pdata hook) already.
>
> If there is no change in the allocation pattern (i.e. inclu
On Thu, Nov 12, 2015 at 09:28:36AM -0700, Jan Beulich wrote:
> >>> On 03.11.15 at 19:15, wrote:
> > Signed-off-by: Ross Lagerwall
> > ---
> > v2: Rebased on keyhandler: rework keyhandler infrastructure
> > v3: Fixed XSM.
> > v4: Removed REVERTED state.
> > Split status and error code.
> >
On 11/13/15 2:07 AM, Jan Beulich wrote:
On 12.11.15 at 23:54, wrote:
>> The switch to Kconfig provides variables prefixed with CONFIG_ with
>> results in a redefinition of this variable.
>
> So I can't see how this can be a separate patch: Either the
> redefinition causes a build failure aft
On 12/11/15 17:30, Stefano Stabellini wrote:
> +static int xen_pvclock_gtod_notify(struct notifier_block *nb,
> +unsigned long was_set, void *priv)
> +{
> + /* Protected by the calling core code serialization */
> + static struct timespec64 next_sync;
> +
> +
On Fri, 2015-11-13 at 13:46 +, Stefano Stabellini wrote:
> On Fri, 13 Nov 2015, Roger Pau Monne wrote:
> > Due to the addition of HVMlite and the requirement to always provide a
> > valid
> > xc_domain_configuration_t, xc_domain_create now always takes an arch
> > domain
> > config, which can b
On Fri, 13 Nov 2015, Roger Pau Monne wrote:
> Due to the addition of HVMlite and the requirement to always provide a valid
> xc_domain_configuration_t, xc_domain_create now always takes an arch domain
> config, which can be NULL in order to mimic previous behaviour.
>
> Add a small stub called xen_
Hi Stefano,
On 12/11/15 17:30, Stefano Stabellini wrote:
> The hypervisor actually exposes an additional field to struct
> pvclock_wall_clock, with the high 32 bit seconds.
>
> Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
Regards,
--
Julien Grall
Hi Stefano,
On 12/11/15 17:30, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini
>
> ---
>
> Changes in v2:
> - rename dom0_op to platform_op
> ---
> arch/arm/include/asm/xen/hypercall.h |2 ++
> arch/arm/xen/enlighten.c |1 +
> arch/arm/xen/hypercall.S
On 13/11/15 12:54, Jan Beulich wrote:
On 13.11.15 at 12:41, wrote:
>> 2) make menuconfig doesn't expose any options => No possibility to
>> select any UART on ARM.
>>
>> The latter is because how you define the option in the Kconfig:
>>
>> config HAS_EXYNOS4210
>> bool
>>
>> Without any
(XEN) [0.00] IRQ limits: 72 GSI, 15304 MSI/MSI-X
(XEN) [0.00] Switched to APIC driver x2apic_cluster.
(XEN) [6.333211] I/O virtualisation enabled
(XEN) [6.339317] - Dom0 mode: Relaxed
(XEN) [6.344720] Interrupt remapping enabled
(XEN) [6.350864] Enabled directed EO
Introduce support for domainGetCPUStats API call and consequently
allow us to use `virsh cpu-stats`. The latter returns a more brief
output than the one provided by`virsh vcpuinfo`.
Signed-off-by: Joao Martins
---
Changes since v1:
- Remove libxl_vcpuinfo_dispose() in favor or using
libxl_vcpui
Introduce support for domainInterfaceStats API call for querying
network interface statistics. Consequently it also enables the
use of `virsh domifstat ` command.
After succesful guest creation we fill the network
interfaces names based on domain, device id and append suffix
if it's emulated in t
1 - 100 of 187 matches
Mail list logo
