flight 63512 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63512/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 60684
test-amd64
flight 63524 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63524/
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
flight 63485 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63485/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 6 xen-boot fail REGR. vs. 62277
test-amd64-i386-xl-qemu
Ian & George, any comments?
>>> On 10/21/2015 at 05:08 PM, in message
<1445418510-19614-4-git-send-email-cy...@suse.com>, Chunyan Liu
wrote:
> Add pvusb APIs, including:
> - attach/detach (create/destroy) virtual usb controller.
> - attach/detach usb device
> - list usb controller and usb
On Wed, Nov 04, 2015 at 09:01:11AM +0800, Bob Liu wrote:
>
> On 11/04/2015 03:44 AM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 02, 2015 at 12:21:39PM +0800, Bob Liu wrote:
> >> Preparatory patch for multiple hardware queues (rings). The number of
> >> rings is unconditionally set to 1, larger n
On Wed, Nov 04, 2015 at 09:11:10AM +0800, Bob Liu wrote:
>
> On 11/04/2015 04:40 AM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 02, 2015 at 12:21:41PM +0800, Bob Liu wrote:
> >> The number of hardware queues for xen/blkfront is set by parameter
> >> 'max_queues'(default 4), while the max value x
On Wed, Nov 04, 2015 at 09:07:12AM +0800, Bob Liu wrote:
>
> On 11/04/2015 04:09 AM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Nov 02, 2015 at 12:21:40PM +0800, Bob Liu wrote:
> >> The per device io_lock became a coarser grained lock after
> >> multi-queues/rings
> >> was introduced, this patch in
On 11/04/2015 04:40 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 02, 2015 at 12:21:41PM +0800, Bob Liu wrote:
>> The number of hardware queues for xen/blkfront is set by parameter
>> 'max_queues'(default 4), while the max value xen/blkback supported is
>> notified
>> through xenstore("multi-que
On 11/04/2015 04:09 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 02, 2015 at 12:21:40PM +0800, Bob Liu wrote:
>> The per device io_lock became a coarser grained lock after multi-queues/rings
>> was introduced, this patch introduced a fine-grained ring_lock for each ring.
>
> s/was introduced/wa
>>>On 04.11.2015 at 1:02, wrote:
> On Fri, 2015-10-30 at 18:57 -0400, Daniel De Graaf wrote:
> > On 10/10/15 12:26, Quan Xu wrote:
> > > Signed-off-by: Quan Xu
> > Acked-by: Daniel De Graaf
>
> Applied, thanks.
>
Ian / Daniel / Wei, Thanks.
Quan
> Ian
___
On 11/04/2015 03:44 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 02, 2015 at 12:21:39PM +0800, Bob Liu wrote:
>> Preparatory patch for multiple hardware queues (rings). The number of
>> rings is unconditionally set to 1, larger number will be enabled in next
>> patch so as to make every single p
Hello,
I've experimented with my X10SAE and I think the problem with being
unable to resume after suspending to RAM has something to do with the
PCI Bridge violating the spec by trying to DMA from another address,
since I got a DMAR error about DMA access on address 05:00.0(but in the
bios event l
flight 63544 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63544/
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 Mon, Nov 02, 2015 at 12:21:42PM +0800, Bob Liu wrote:
> Split per ring information to an new structure "xen_blkif_ring", so that one
> vbd
> device can associate with one or more rings/hardware queues.
s/can associate/can be associated/
>
> Introduce 'pers_gnts_lock' to protect the pool of pe
On Tue, 2015-11-03 at 05:38 -0700, Jan Beulich wrote:
> > > > On 03.11.15 at 11:16, wrote:
> > So you agree that this change makes the source code make more sense
> > ("looks like an improvement at the source level"), but you think
> > that
> > this will make the compiled code less efficient; and
flight 63476 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63476/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 6 xen-boot fail REGR. vs. 63398
test-amd64-amd64-pygru
On Mon, Nov 02, 2015 at 12:21:41PM +0800, Bob Liu wrote:
> The number of hardware queues for xen/blkfront is set by parameter
> 'max_queues'(default 4), while the max value xen/blkback supported is notified
> through xenstore("multi-queue-max-queues").
That is not right.
s/The number/The max numb
On Mon, Nov 02, 2015 at 12:21:40PM +0800, Bob Liu wrote:
> The per device io_lock became a coarser grained lock after multi-queues/rings
> was introduced, this patch introduced a fine-grained ring_lock for each ring.
s/was introduced/was introduced (see commit titled XYZ)/
s/introdued/introduces/
On Mon, Nov 02, 2015 at 12:21:39PM +0800, Bob Liu wrote:
> Preparatory patch for multiple hardware queues (rings). The number of
> rings is unconditionally set to 1, larger number will be enabled in next
> patch so as to make every single patch small and readable.
s/next patch/"xen/blkfront: negot
On Mon, Nov 02, 2015 at 12:21:38PM +0800, Bob Liu wrote:
> 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.
Add support for applying alternative sections within xsplice modules. At
module load time, apply any alternative sections that are found.
Signed-off-by: Ross Lagerwall
---
xen/arch/x86/Makefile | 2 +-
xen/arch/x86/alternative.c| 12 ++--
xen/common/xsplice.c
Hi Stefano,
[auto build test ERROR on arm64/for-next/core]
[cannot apply to: xen-tip/linux-next]
[also ERROR on: v4.3 next-20151103]
url:
https://github.com/0day-ci/linux/commits/Stefano-Stabellini/xen-arm-arm64-CONFIG_PARAVIRT-and-stolen-ticks-accounting/20151104-002433
base: https
On 08/05/2015 09:55 AM, Martin Pohlack wrote:
Hi,
Another high-level point to think about is how we want to handle inlined
__LINE__ references. This problem is related to hotpatch construction
and potentially has influence on the design of the hotpatching
infrastructure in Xen.
Let me try to e
flight 63542 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63542/
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
From: Konrad Rzeszutek Wilk
The underlaying toolstack code to do the basic
operations when using the XEN_XSPLICE_op syscalls:
- upload the payload,
- get status of an payload,
- list all the payloads,
- apply, check, replace, and revert the payload.
Signed-off-by: Konrad Rzeszutek Wilk
Sign
From: Konrad Rzeszutek Wilk
A mechanism is required to binarily patch the running hypervisor with new
opcodes that have come about due to primarily security updates.
This document describes the design of the API that would allow us to
upload to the hypervisor binary patches.
This document has b
From: Konrad Rzeszutek Wilk
A simple tool that allows an system admin to perform
basic xsplice operations:
- Upload a xsplice file (with an unique id)
- List all the xsplice payloads loaded.
- Apply, revert, replace, unload, or check the payload using the
unique id.
- Do all three - uploa
Add support for handling bug frames contained with xsplice modules. If a
trap occurs search either the kernel bug table or an applied module's
bug table depending on the instruction pointer.
Signed-off-by: Ross Lagerwall
---
xen/arch/x86/traps.c | 30 -
xen/common/symbols.c
Add support for exception tables contained within xsplice modules. If an
exception occurs search either the main exception table or a particular
active module's exception table depending on the instruction pointer.
Signed-off-by: Ross Lagerwall
---
xen/arch/x86/extable.c| 36
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 payloads,
- check*1, apply*1, replace*1, and unloa
Add support for loading xsplice payloads. This is somewhat similar to
the Linux kernel module loader, implementing the following steps:
- Verify the elf file.
- Parse the elf file.
- Allocate a region of memory mapped within a free area of
[xen_virt_end, XEN_VIRT_END].
- Copy allocated sections i
Implement support for the apply, revert and replace actions.
To perform and action on a payload, the hypercall sets up a data
structure to schedule the work. A hook is added in all the
return-to-guest paths to check for work to do and execute it if needed.
In this way, patches can be applied with
Signed-off-by: Ross Lagerwall
---
xen/include/xen/elfstructs.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/xen/include/xen/elfstructs.h b/xen/include/xen/elfstructs.h
index 12ffb82..5ca2956 100644
--- a/xen/include/xen/elfstructs.h
+++ b/xen/include/xen/elfstructs.h
Add some elf routines and data structures in preparation for loading an
xsplice payload.
Signed-off-by: Ross Lagerwall
---
xen/common/Makefile | 1 +
xen/common/xsplice_elf.c | 122 ++
xen/include/xen/xsplice_elf.h | 44 +++
3
Use register names for variables, rather than their content for leaf 1.
Reduce the number of cpuid instructions issued. Also drop some trailing
whitespace.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v2: Record the correct registers for the 0x8001 feature leaves
This is the initial implementation of xSplice, live patching for Xen.
Patch series overview:
Patch 1: Design document
Patches 2, 5-11: Hypervisor implementation
Patches 3, 4: Toolstack changes
Live patches work at the function level by replacing functions. Any
function may be replaced, but wheth
On Mon, Nov 02, 2015 at 12:21:37PM +0800, Bob Liu wrote:
> 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
I queued this up, but obviously we need to wait for the Xen version to
be accepted.
> --
>
On Fri, Oct 30, 2015 at 07:24:27AM +0800, Bob Liu wrote:
> 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
Reviewed-by: Konrad Rzeszutek Wilk
> --
> v2: Comments from Konrad
> ---
> xen/include/publi
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 grant table 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 grant table.
On multi-socket systems, the contention results in the locked compare swap
operation failing fre
On Wed, 4 Nov 2015, kbuild test robot wrote:
> Hi Stefano,
>
> [auto build test ERROR on arm64/for-next/core]
> [cannot apply to: xen-tip/linux-next]
> [also ERROR on: v4.3 next-20151103]
>
> url:
> https://github.com/0day-ci/linux/commits/Stefano-Stabellini/xen-arm-a
On Tue, Nov 03, 2015 at 05:30:32PM +, Ian Campbell wrote:
> On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
> > Hi all,
> >
> > I've start to look at loading the BIOS and the ACPI tables via the
> > toolstack instead of having them embedded in the hvmloader binary. After
> > this patc
On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
At first it seems like not loading the ACPI table already was an unnoticed
functional regression from the switch to HVM using the regular PV domain
builder. But then looking at that code I see there is an acpi_module field
which Roger added
On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
Please remember to CC the relevant maintainers.
> scratch_alloc() set scratch_start to the last byte of the current
> allocation. The value of scratch_start is then reused as is (if it is
> already aligned) in the next allocation. This re
On Mon, 2015-10-26 at 16:03 +, Anthony PERARD wrote:
> Hi all,
>
> I've start to look at loading the BIOS and the ACPI tables via the
> toolstack instead of having them embedded in the hvmloader binary. After
> this patch series, hvmloader compilation would be indenpendant from
> SeaBIOS
> and
On Mon, Nov 02, 2015 at 04:45:37PM +, Ross Lagerwall wrote:
> On 11/02/2015 04:37 PM, Wei Liu wrote:
> >On Mon, Nov 02, 2015 at 11:17:38AM +, Ross Lagerwall wrote:
> >>Previously, xenconsoled's daemonize function would do nothing if its
> >>parent process is init (as it is under systemd but
Hi Stefano,
[auto build test ERROR on arm64/for-next/core]
[cannot apply to: xen-tip/linux-next]
[also ERROR on: v4.3 next-20151103]
url:
https://github.com/0day-ci/linux/commits/Stefano-Stabellini/xen-arm-arm64-CONFIG_PARAVIRT-and-stolen-ticks-accounting/20151104-002433
base: https
On Tue, 2015-11-03 at 16:49 +, Ian Campbell wrote:
> On Mon, 2015-11-02 at 12:30 +, Stefano Stabellini wrote:
> > Try to use "xen-qemudepriv-domid$domid" first, then
> > "xen-qemudepriv-shared" and root if everything else fails.
> >
> > The uids need to be manually created by the user or,
On Mon, 2015-11-02 at 18:04 +, George Dunlap wrote:
> On 29/10/15 23:04, Dario Faggioli wrote:
> > @@ -936,15 +936,19 @@ csched_vcpu_remove(const struct scheduler
> > *ops, struct vcpu *vc)
> > vcpu_unpause(svc->vcpu);
> > }
> >
> > +lock = vcpu_schedule_lock_irq(vc);
> > +
On Tue, 2015-11-03 at 17:08 +, Ian Campbell wrote:
> On Wed, 2015-10-28 at 16:51 +, Wei Liu wrote:
> > On Wed, Oct 28, 2015 at 05:43:51PM +0100, Dario Faggioli wrote:
> > > In fact, right now, failing at destroying a cpupool is just
> > > not reported to the user in any explicit way.
> > >
On Wed, 2015-10-28 at 16:51 +, Wei Liu wrote:
> On Wed, Oct 28, 2015 at 05:43:51PM +0100, Dario Faggioli wrote:
> > In fact, right now, failing at destroying a cpupool is just
> > not reported to the user in any explicit way.
> >
> > Let's log an error, as it is customary for xl in these cases
On Tue, 2015-10-27 at 15:39 +, Julien Grall wrote:
> The variable "mod" is defined twice with different value. This make the
> code confusing to read.
>
> Rename the 2 "mod" in something more meaningful.
>
> Signed-off-by: Julien Grall
Acked + applied.
On Thu, 2015-10-22 at 17:32 +0100, Ian Campbell wrote:
> On Wed, 2015-10-21 at 15:15 +0100, Wei Liu wrote:
> > That directory is used to store guest memory dump which contains
> > sensitive information.
> >
> > Signed-off-by: Wei Liu
>
> Acked-by: Ian Campbell
Applied.
> Have you audited all
On Fri, 2015-10-30 at 18:57 -0400, Daniel De Graaf wrote:
> On 10/10/15 12:26, Quan Xu wrote:
> > Signed-off-by: Quan Xu
> Acked-by: Daniel De Graaf
Applied, thanks.
Ian
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-deve
On Thu, 2015-10-29 at 11:26 +, Wei Liu wrote:
> On Thu, Oct 29, 2015 at 11:02:54AM +, Olaf Hering wrote:
> > xendomains will manage guests behind libvirts back:
> > - libvirt starts a guest
> > - that guest can be "managed" by libvirt and xl at the same time
> > - when xendomains runs on sh
On Mon, 2015-10-26 at 10:52 +, Wei Liu wrote:
> On Fri, Oct 23, 2015 at 04:44:11PM +0100, Ian Jackson wrote:
> > def_getopt would print a message to stderr, but blunder on anyway.
> >
> > Sadly this is probably not a backport candidate.
> >
> > Signed-off-by: Ian Jackson
>
> Acked-by: Wei L
On Mon, 2015-11-02 at 12:30 +, Stefano Stabellini wrote:
> Try to use "xen-qemudepriv-domid$domid" first, then
> "xen-qemudepriv-shared" and root if everything else fails.
>
> The uids need to be manually created by the user or, more likely, by the
> xen package maintainer.
>
> Expose a devic
On Tue, 2015-10-27 at 10:40 -0600, Jan Beulich wrote:
> > > > On 27.10.15 at 17:32, wrote:
> > And what are you suggesting about the patch? Create a separate OMAP
> > specific header?
>
> For #define-s used by only a single source file I'd suggest putting
> them into the source file instead of in
flight 38244 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38244/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-amd64-weekly-netinst-pygrub 3 host-install(3) broken REGR. vs.
38215
Register the runstate_memory_area with the hypervisor.
Use pv_time_ops.steal_clock to account for stolen ticks.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- don't use paravirt_steal_rq_enabled: we do not support retrieving
stolen ticks for vcpus other than one we are running on.
Chan
ifdef CONFIG_PARAVIRT in sched/core.c is redundant, as asm/paravirt.h
is already protected by #ifdef CONFIG_PARAVIRT.
Add include asm/paravirt.h to cputime.c, as steal_account_process_tick
calls paravirt_steal_clock, which is defined in paravirt.h.
Signed-off-by: Stefano Stabellini
CC: mi...@red
Introduce CONFIG_PARAVIRT and PARAVIRT_TIME_ACCOUNTING on ARM64.
Necessary duplication of paravirt.h and paravirt.c with ARM.
The only paravirt interface supported is pv_time_ops.steal_clock, so no
runtime pvops patching needed.
This allows us to make use of steal_account_process_tick for stolen
Introduce CONFIG_PARAVIRT and PARAVIRT_TIME_ACCOUNTING on ARM.
The only paravirt interface supported is pv_time_ops.steal_clock, so no
runtime pvops patching needed.
This allows us to make use of steal_account_process_tick for stolen
ticks accounting.
Signed-off-by: Stefano Stabellini
Acked-by:
On Tue, Nov 03, 2015 at 12:07:27AM +, Hao, Xudong wrote:
> Wei,
>
> I checked the latest OVMF changeset on Xen staging tree and master tree, both
> are af9785a9ed61daea52b47f0bf448f1f228beee1e. This commit is what I used.
> OVMF_UPSTREAM_REVISION ?= af9785a9ed61daea52b47f0bf448f1f228beee1e
Signed-off-by: Stefano Stabellini
Acked-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk
CC: konrad.w...@oracle.com
---
Changes in v10:
- rebase
- remove ia64 changes
---
arch/x86/xen/time.c | 76 +
drivers/xen/Makefile |2 +-
drivers/xen/ti
Hi all,
I dusted off this series from Jan 2014. Patch #2 and #3 still need an ack.
This patch series introduces stolen ticks accounting for Xen on ARM and
ARM64. Stolen ticks are clocksource ticks that have been "stolen" from
the cpu, typically because Linux is running in a virtual machine and
flight 63475 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63475/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in
63400 pass in 63475
test-armhf-armhf-
On Tue, 2015-11-03 at 08:31 -0700, Jan Beulich wrote:
> > > > On 03.11.15 at 14:39, wrote:
> > On Tue, 2015-11-03 at 05:50 -0700, Jan Beulich wrote:
> > > That's certainly an option on x86 too, the more that the x86_64/
> > > subtree is a remnant of x86_32 days only anyway. Just that doing
> > > t
>>> On 03.11.15 at 14:39, wrote:
> On Tue, 2015-11-03 at 05:50 -0700, Jan Beulich wrote:
>> That's certainly an option on x86 too, the more that the x86_64/
>> subtree is a remnant of x86_32 days only anyway. Just that doing
>> this will mean quite a bit more work (not the least because, to be
>>
On 03/11/15 14:18, Stefano Stabellini wrote:
>> +#define set_xen_guest_handle_raw(hnd, val) \
>> +do {\
>> +/* Check if the handle is 64-bit (i.e 8-byte) */\
>> +(void) s
This run is configured for baseline tests only.
flight 38245 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38245/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 19 guest-start/deb
On Tue, 2015-11-03 at 22:57 +0800, Fu Wei wrote:
> Hi Vladimir,
>
> After discussing with Ian Campbell, Since we already can load all
> the necessary binaries for Xen boot on arm64 for now, we don't really
> need "xen_module" command now.
> But maybe someday , xen need a new type of binary in b
On 02/11/15 17:59, Andrew Cooper wrote:
> Use register names for variables, rather than their content for leaf 1.
> Reduce the number of cpuid instructions issued. Also drop some trailing
> whitespace.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Apologies - this patch is broken an
Hi Vladimir,
After discussing with Ian Campbell, Since we already can load all
the necessary binaries for Xen boot on arm64 for now, we don't really
need "xen_module" command now.
But maybe someday , xen need a new type of binary in boot time, then
we still need this support.
So I will submit
This run is configured for baseline tests only.
flight 38243 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38243/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 6 xen-boot
On Mon, Nov 02, 2015 at 05:59:45PM +, Andrew Cooper wrote:
> Use register names for variables, rather than their content for leaf 1.
> Reduce the number of cpuid instructions issued. Also drop some trailing
> whitespace.
>
> No functional change.
I checked for that and:
Reviewed-by: Konrad
On Mon, Nov 02, 2015 at 05:59:44PM +, Andrew Cooper wrote:
> It is __read_mostly, so repeatedly writing to it is suboptiomal. As the
> MTRRs have already been set up, nothing good will come from its value
> changing across CPUs.
Reviewed-by: Konrad Rzeszutek Wilk
>
> Signed-off-by: Andrew C
On Tue, 2015-11-03 at 14:01 +, Julien Grall wrote:
> Hi,
>
> On 03/11/15 12:35, Ian Campbell wrote:
> > On Mon, 2015-11-02 at 15:55 +, Stefano Stabellini wrote:
> > >
> > > > +/*
> > > > + * Macro to set a guest pointer in the handle.
> > > > + *
> > > > + * Note that it's not possible to
On Mon, Nov 02, 2015 at 05:59:43PM +, Andrew Cooper wrote:
Reviewed-by: Konrad Rzeszutek Wilk
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> ---
> xen/arch/x86/cpu/common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/cpu/common.c b/xen
On Fri, 30 Oct 2015, Julien Grall wrote:
> The current implementation of set_xen_guest_handle_raw is using the
> keyword "typeof" which is not part of C spec.
>
> Furthermore, when the guest handle is defined in ARM32 guest, the
> pointer will always be smaller than the handle. Based on the C99 sp
Hi,
On 03/11/15 12:35, Ian Campbell wrote:
> On Mon, 2015-11-02 at 15:55 +, Stefano Stabellini wrote:
>>
>>> +/*
>>> + * Macro to set a guest pointer in the handle.
>>> + *
>>> + * Note that it's not possible to implement safely a macro to retrieve the
>>> + * handle unless the guest is built
flight 63473 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63473/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate
fail REGR. vs. 59254
tes
On Tue, 2015-11-03 at 05:50 -0700, Jan Beulich wrote:
> > > >
> > > Considering that Andrew was fine with the x86 parts, I'd want to
> > > change the approach (the x86 side of which I understand is of
> > > particular concern to you) only if you're convinced this alternative
> > > approach is suff
>>> On 03.11.15 at 13:22, wrote:
> On Mon, 2015-11-02 at 09:11 -0700, Jan Beulich wrote:
>> > Does all of that fall out from a desire to reuse __FILE__? If so I'm
>> > inclined to suggest that -DBUILD_FILENAME_PREFIX="compat/" or whatever
>> > would seem likely to me to end up less strange (but ma
>>> On 03.11.15 at 11:57, wrote:
> On 03/11/15 07:21, Jan Beulich wrote:
> On 30.10.15 at 16:36, wrote:
>>> On 30/10/15 13:16, Jan Beulich wrote:
>>> On 30.10.15 at 13:50, wrote:
> El 14/10/15 a les 16.37, Jan Beulich ha escrit:
> On 02.10.15 at 17:48, wrote:
>>> Signed-
On Mon, 2015-11-02 at 12:12 -0500, Konrad Rzeszutek Wilk wrote:
> And use it amongst the callers of this function.
I expect this will also need some (hopefully trivial) changes for ARM too?
>
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> xen/arch/x86/mm/hap/hap.c | 2 +-
> xen/arch/x86/
>>> On 03.11.15 at 11:16, wrote:
> On Fri, Oct 30, 2015 at 5:00 PM, Jan Beulich wrote:
> On 30.10.15 at 17:33, wrote:
>>> On Fri, 2015-10-30 at 10:25 -0600, Jan Beulich wrote:
> > > On 30.10.15 at 16:09, wrote:
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit
On Mon, 2015-11-02 at 15:55 +, Stefano Stabellini wrote:
>
> > +/*
> > + * Macro to set a guest pointer in the handle.
> > + *
> > + * Note that it's not possible to implement safely a macro to retrieve the
> > + * handle unless the guest is built with strict aliasing disabling.
> > + * Hence,
On Mon, 2015-11-02 at 09:11 -0700, Jan Beulich wrote:
> > > >
> > It seems quite inconsistent to me to have xen/arch/x86/x86_64/Makefile
> > building some files directly and xen/arch/x86/Makefile to be building
> > another subset of those files via x86_64/FOO.o. Even more so that other
> > than co
On Tue, 2015-11-03 at 03:02 -0700, Jan Beulich wrote:
> > > > On 02.11.15 at 15:01, wrote:
> > On Thu, 2015-10-29 at 04:05 -0600, Jan Beulich wrote:
> > > Recent ld warns about libxenlight.so's dependency libraries not being
> > > available, which can be easily avoided by not just passing the raw
This run is configured for baseline tests only.
flight 38242 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38242/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 6 xen-bo
On 03/11/15 07:21, Jan Beulich wrote:
On 30.10.15 at 16:36, wrote:
>> On 30/10/15 13:16, Jan Beulich wrote:
>> On 30.10.15 at 13:50, wrote:
El 14/10/15 a les 16.37, Jan Beulich ha escrit:
On 02.10.15 at 17:48, wrote:
>> Signed-off-by: Roger Pau Monné
>> Cc: Jan Be
>>> On 03.11.15 at 10:58, wrote:
> On 02/11/15 14:10, Jan Beulich wrote:
> On 02.11.15 at 09:03, wrote:
>>> Based on above information, we propose to continue spin-timeout
>>> model w/ some adjustment, which fixes current timeout concern
>>> and also allows limited ATS support in a light way:
On Fri, Oct 30, 2015 at 5:00 PM, Jan Beulich wrote:
On 30.10.15 at 17:33, wrote:
>> On Fri, 2015-10-30 at 10:25 -0600, Jan Beulich wrote:
>>> > > > On 30.10.15 at 16:09, wrote:
>>> > --- a/xen/common/sched_credit.c
>>> > +++ b/xen/common/sched_credit.c
>>> > @@ -252,13 +252,12 @@ __runq_ele
>>> On 02.11.15 at 15:01, wrote:
> On Thu, 2015-10-29 at 04:05 -0600, Jan Beulich wrote:
>> Recent ld warns about libxenlight.so's dependency libraries not being
>> available, which can be easily avoided by not just passing the raw
>> library name on ld's command line.
>
>> In the course of check
On 02/11/15 14:10, Jan Beulich wrote:
On 02.11.15 at 09:03, wrote:
>> Based on above information, we propose to continue spin-timeout
>> model w/ some adjustment, which fixes current timeout concern
>> and also allows limited ATS support in a light way:
>>
>> 1) reduce spin timeout to 1ms, wh
flight 63470 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63470/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 5 kernel-build fail REGR. vs. 62648
Tests which are failin
From: Borislav Petkov
paravirt_patch_ignore() is completely unused and paravirt_patch_nop()
doesn't do a whole lot. Remove them both.
Signed-off-by: Borislav Petkov
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Chris Wright
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Jeremy Fitzhardinge
Cc: Juer
BTW, In the previous discussion, we will do the PI state adjustment in
vmx_do_resume, however, seems this is not a good place to do this, since this
function gets called only if the scheduling occurs, no matter it switches to
another vCPU or continue runs the current vCPU. If no scheduling happe
This patch includes the following aspects:
- Handling logic when vCPU is blocked:
* Add a global vector to wake up the blocked vCPU
when an interrupt is being posted to it (This part
was sugguested by Yang Zhang ).
* Define two per-cpu variables:
1. pi_blocked_vcpu:
1 - 100 of 120 matches
Mail list logo
