>>> On 11.01.16 at 18:17, wrote:
> On 11/01/16 14:44, Jan Beulich wrote:
> On 11.01.16 at 14:59, wrote:
>>> Currently, hypercalls issued from HVM userspace will unconditionally fail
>>> with -EPERM.
>>>
>>> This is inflexible, and a guest may wish to allow userspace to make
>>> hypercalls.
>>
This run is configured for baseline tests only.
flight 38620 qemu-upstream-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38620/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-vhd 9 debian-di-install
flight 77819 linux-3.16 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77819/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 76945
test-amd64-amd64-xl-credit2 17
Hi,alls,
I want to achieve that the xen kernel can xend a notification to a domu,
and then the domu can receive the notification and handle this notification.
now,I think the event channel can achieve it.But I don't have enough
information about event channel. Can who describe in detail the p
On 01/10/2016 06:18 AM, Michael S. Tsirkin wrote:
On mips dma_rmb, dma_wmb, smp_store_mb, read_barrier_depends,
smp_read_barrier_depends, smp_store_release and smp_load_acquire match
the asm-generic variants exactly. Drop the local definitions and pull in
asm-generic/barrier.h instead.
This sta
OASIS members and other interested parties,
The OASIS Virtual I/O Device (VIRTIO) TC members [1] have produced an
updated Committee Specification Draft (CSD) and submitted this
specification for 15-day public review:
Virtual I/O Device (VIRTIO) Version 1.0
Committee Specification Draft 05 / Publi
flight 77812 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77812/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 12 guest-saverestore fail REGR. vs. 77554
test-amd64-amd64-xl-qe
Hey,
The machine is an X5-2 which is a Haswell based E5-2699 v3.
We are trying to launch to use the nested virtualization. The
guest is a simple VMware vSphere 6.0 with 32GB, 8 CPUs.
The guest than that is launched within VMware is a 2 VCPU 2GB Linux
(OEL6 to be exact). During its bootup Xen cra
I used 6bb9ead762bf749af11ea225fc2a74db1b93c105 yesterday, this version don't
include commit 349a3b1cc.
Thanks,
-Xudong
> -Original Message-
> From: Cao jin [mailto:caoj.f...@cn.fujitsu.com]
> Sent: Tuesday, January 12, 2016 10:01 AM
> To: Hao, Xudong ; Stefano Stabellini
>
> Cc: Lars
Hi
On 01/11/2016 05:53 PM, Hao, Xudong wrote:
Stefano,
Patch http://marc.info/?l=qemu-devel&m=145137863501079 don't works for qemu at
all, some conflict when git apply.
Patch http://marc.info/?l=qemu-devel&m=145137863501079 is based on patch
http://marc.info/?l=qemu-devel&m=145172165010604, r
On 01/09/2016 12:27 AM, Ian Campbell wrote:
> On Fri, 2016-01-08 at 14:38 +0800, Wen Congyang wrote:
>> For example: if the secondary host is down, and we fail to send the data
>> to
>> the secondary host. xc_domain_save() returns 0.
>
> Just to be check: On failure in this way xc_domain_save() re
On 01/09/2016 12:20 AM, Ian Campbell wrote:
> On Fri, 2016-01-08 at 14:38 +0800, Wen Congyang wrote:
>> stream_continue() is used for migration to read emulator
>> xenstore data and emulator context. For remus, if we do
>> failover, we have read it in the checkpoint cycle, and
>> we only need to co
flight 77788 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77788/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 6 xen-boot fail REGR. vs. 77684
Regressions which are reg
flight 77785 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77785/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 60684
Regression
On Tue, Dec 15, 2015 at 12:40 PM, Michael S. Tsirkin wrote:
> On Mon, Dec 14, 2015 at 10:27:52AM -0800, Andy Lutomirski wrote:
>> On Mon, Dec 14, 2015 at 6:12 AM, Michael S. Tsirkin wrote:
>> > On Mon, Dec 14, 2015 at 02:00:05PM +, David Vrabel wrote:
>> >> On 07/12/15 16:19, Stefano Stabelli
Hi David,
On Mon, 11 Jan 2016 11:32:01 + David Vrabel wrote:
>
> Please git pull the following tag:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-4.5-rc0-tag
>
> xen: features and fixes for 4.5-rc0
>
> - - Stolen ticks and PV wallclock support for arm/arm64.
>
flight 38618 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38618/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-armhf-sid-netboot-pygrub 9 debian-di-install fail like 38586
test-amd64-i386-amd
Introduce an option where the user can modifiy the maximum number of
supported physical CPUs.
CC: Ian Campbell
CC: Stefano Stabellini
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Doug Goldstein
---
xen/arch/Kconfig | 8
xen/arch/arm/Kconfig | 2 ++
xen/arch/
Use CONFIG_NR_CPUS from Kconfig as NR_CPUS instead of the previous
MAX_PHYS_CPUS variable from make. Remove the creation of MAX_PHYS_CPUS
as well.
CC: Ian Campbell
CC: Stefano Stabellini
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Doug Goldstein
---
xen/Rules.mk
On Mon, 2016-01-11 at 13:00 +0200, Michael S. Tsirkin wrote:
> As part of memory barrier cleanup, this patchset
> extends checkpatch to make it easier to stop
> incorrect memory barrier usage.
Thanks Michael.
Acked-by: Joe Perches
___
Xen-devel maili
This run is configured for baseline tests only.
flight 38617 xen-4.3-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38617/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 19 guest-start/
flight 77752 qemu-upstream-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77752/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 62414
test-am
On 11/01/16 18:40, David Vrabel wrote:
> On 11/01/16 18:32, Andrew Cooper wrote:
>> On 11/01/16 18:26, David Vrabel wrote:
>>> On 11/01/16 17:17, Andrew Cooper wrote:
So from one point of view, sufficient justification for this change is
"because the Linux way isn't the only valid way to
On 11/01/16 18:32, Andrew Cooper wrote:
> On 11/01/16 18:26, David Vrabel wrote:
>> On 11/01/16 17:17, Andrew Cooper wrote:
>>> So from one point of view, sufficient justification for this change is
>>> "because the Linux way isn't the only valid way to do this".
>> "Because we can" isn't a good ju
On 11/01/16 18:26, David Vrabel wrote:
> On 11/01/16 17:17, Andrew Cooper wrote:
>> So from one point of view, sufficient justification for this change is
>> "because the Linux way isn't the only valid way to do this".
> "Because we can" isn't a good justification for adding something new.
"Becaus
On 11/01/16 17:17, Andrew Cooper wrote:
> So from one point of view, sufficient justification for this change is
> "because the Linux way isn't the only valid way to do this".
"Because we can" isn't a good justification for adding something new.
Particularly something that is trivially easy to (ac
flight 77781 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77781/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 62112
build-a
On Mon, Jan 11, 2016 at 11:15:43PM +0530, Harmandeep Kaur wrote:
> On Mon, Jan 11, 2016 at 11:00 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Mon, Jan 11, 2016 at 10:56:07PM +0530, Harmandeep Kaur wrote:
> >> On Mon, Jan 11, 2016 at 8:23 PM, Konrad Rzeszutek Wilk
> >> wrote:
> >> > On Mon, Jan 11, 2
flight 77780 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77780/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 62044
build-a
On Mon, Jan 11, 2016 at 05:58:47PM +, Andrew Cooper wrote:
> On 11/01/16 17:11, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 11, 2016 at 04:51:19PM +, Andrew Cooper wrote:
> >> Currently, hypercalls issued from HVM userspace will unconditionally fail
> >> with
> >> -EPERM.
> >>
> >> This i
On 11/01/16 17:11, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 11, 2016 at 04:51:19PM +, Andrew Cooper wrote:
>> Currently, hypercalls issued from HVM userspace will unconditionally fail
>> with
>> -EPERM.
>>
>> This is inflexible, and a guest may wish to allow userspace to make
>> hypercalls.
On Mon, Jan 11, 2016 at 11:00 PM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Jan 11, 2016 at 10:56:07PM +0530, Harmandeep Kaur wrote:
>> On Mon, Jan 11, 2016 at 8:23 PM, Konrad Rzeszutek Wilk
>> wrote:
>> > On Mon, Jan 11, 2016 at 12:57:27AM +0530, Harmandeep Kaur wrote:
>> >> Hi,
>> >>
>> >> I tried
On Mon, Jan 11, 2016 at 10:56:07PM +0530, Harmandeep Kaur wrote:
> On Mon, Jan 11, 2016 at 8:23 PM, Konrad Rzeszutek Wilk
> wrote:
> > On Mon, Jan 11, 2016 at 12:57:27AM +0530, Harmandeep Kaur wrote:
> >> Hi,
> >>
> >> I tried to modify and compile some of Xen 4.7's code
> >> (cloned from git clon
On Mon, Jan 11, 2016 at 8:23 PM, Konrad Rzeszutek Wilk
wrote:
> On Mon, Jan 11, 2016 at 12:57:27AM +0530, Harmandeep Kaur wrote:
>> Hi,
>>
>> I tried to modify and compile some of Xen 4.7's code
>> (cloned from git clone git://xenbits.xen.org/xen.git)
>> and even with a very minor change (patch in
On 11/01/16 14:44, Jan Beulich wrote:
On 11.01.16 at 14:59, wrote:
>> Currently, hypercalls issued from HVM userspace will unconditionally fail
>> with -EPERM.
>>
>> This is inflexible, and a guest may wish to allow userspace to make
>> hypercalls.
> I thought previous discussion had made cle
On 1/11/16 10:49 AM, Jan Beulich wrote:
On 11.01.16 at 17:31, wrote:
>> There have been a good deal number of different downstreams that have
>> been encouraging of changes like this but it seems like you are
>> fundamentally opposed. Which is plainly discouraging to people to
>> attempt to e
On Mon, Jan 11, 2016 at 04:51:19PM +, Andrew Cooper wrote:
> Currently, hypercalls issued from HVM userspace will unconditionally fail with
> -EPERM.
>
> This is inflexible, and a guest may wish to allow userspace to make
> hypercalls.
>
> Introduce HVMOP_set_hypercall_dpl which allows the gu
On 1/11/16 9:19 AM, Wei Liu wrote:
> On Fri, Jan 08, 2016 at 12:49:07PM -0600, Doug Goldstein wrote:
> [...]
>> Ok so I'm at a loss what steps I need to take. I've submitted patches to
>> put the config in /boot so that this check can be made but there's a
>> disagreement if that's even necessary o
On 01/07/2016 10:13 AM, Ian Campbell wrote:
> On Tue, 2015-12-22 at 18:44 +, Ian Jackson wrote:
>> This allows code elsewhere in libxl to find out what options a device
>> model executable supports. This is done by searching the usage
>> message for fixed strings.
> Has anyone (ever, not neces
flight 77743 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77743/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 9 debian-install fail like 77410
Tests which did not succeed,
>>> On 11.01.16 at 17:31, wrote:
> There have been a good deal number of different downstreams that have
> been encouraging of changes like this but it seems like you are
> fundamentally opposed. Which is plainly discouraging to people to
> attempt to engage upstream.
I could see such a reaction
Hi folks,
please find attached 2014 and 2015 contribution stats, including some of the
tags. To compare like with like, the 2015 figures do contain repos which were
taken out of xen.git. They also include osstest, as I used to track these in
the past.
The company figures in the 2015 file may h
This run is configured for baseline tests only.
flight 38616 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38616/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub 6 xen-boot
Currently, hypercalls issued from HVM userspace will unconditionally fail with
-EPERM.
This is inflexible, and a guest may wish to allow userspace to make
hypercalls.
Introduce HVMOP_set_hypercall_dpl which allows the guest to alter the
permissions check for hypercalls. It behaves exactly like t
On 1/11/16 9:43 AM, Jan Beulich wrote:
On 11.01.16 at 16:10, wrote:
>> Jan Beulich writes:
>> On 08.01.16 at 22:22, wrote:
+config SCHED_CREDIT
+ bool "Credit scheduler support"
+ default y
>>>
>>> I continue to think that not making the primary scheduler configurable
>>
>>> On 11.01.16 at 17:01, wrote:
> On Mon, Jan 11, 2016 at 02:02:54AM -0700, Jan Beulich wrote:
>> >>> On 08.01.16 at 18:31, wrote:
>> >> >> > The rest: XENVER_[version|capabilities|
>> >> >> > parameters|get_features|page_size|guest_handle] behave
>> >> >> > as before - allowed by default for al
My previous patch 03809ae7 "document transmit and receive wire formats
separately" improved documentation of the receive and transmit wire
formats but further clarifications were requested.
This patch adds those clarifications.
Signed-off-by: Paul Durrant
Cc: Ian Campbell
Cc: Ian Jackson
Cc: J
This series documents changes needed to support toeplitz hashing in a
backend, configurable by the frontend.
Patch #1 adds further clarifications to the receive and transmit wire
formats.
Patch #2 documents a new 'control ring' for passing bulk data between
frontend and backend. This is needed fo
This patch documents a new shared ring between frontend and backend that
can be used to pass bulk out-of-band data, such as that required to
implement toeplitz hashing in the backend such that it is configurable by
the frontend (which is needed to support NDIS RSS for Windows guests).
The patch th
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 11 January 2016 15:53
> To: Paul Durrant
> Cc: Ian Campbell; Ian Jackson; xen-de...@lists.xenproject.org; Keir
> (Xen.org); Tim (Xen.org)
> Subject: Re: [PATCH v5 1/2] public/io/netif.h: document transmit and receiv
On Mon, Jan 11, 2016 at 11:47:39AM +0200, Pasi Kärkkäinen wrote:
> Hello,
>
> And now all the components listed below are released and available easily.
>
> Dom0:
> - Qemu 2.5 has virtio-gpu 3D/OpenGL acceleration support for VMs.
>
> DomU:
> - Linux 4.4 kernel has the virtio-gpu drm driver.
> -
On Mon, Jan 11, 2016 at 04:52:10PM +0800, Liang Li wrote:
> If hardware support memory protect externsion, expose this feature
extension
> to guest by default. Users don't have to use a 'cpuid= ' option in
> config file to turn it on.
>
> Signed-off-by: Liang Li
> ---
> tools/libxc/xc_cpufeatur
On Mon, Jan 11, 2016 at 02:02:54AM -0700, Jan Beulich wrote:
> >>> On 08.01.16 at 18:31, wrote:
> >> >> > The rest: XENVER_[version|capabilities|
> >> >> > parameters|get_features|page_size|guest_handle] behave
> >> >> > as before - allowed by default for all guests.
> >> >> >
> >> >> > This is w
On 9/22/2015 8:06 AM, Jan Beulich wrote:
... in anticipation of this possibly going to get used by guests for
basic thinks like memset() or clearing or pages.
Since the emulation doesn't use clzero itself, checking the guest's
CPUID for the feature to be exposed is (intentionally) being avoided
>>> On 11.01.16 at 16:25, wrote:
> Currently there is no documented wire format for guest receive-side
> packets but the location of the 'wire format' comment block suggests
> it is the same as transmit-side. This is almost true but there is a
> subtle difference in the use of the 'size' field for
On Mon, 2016-01-11 at 08:30 -0700, Jan Beulich wrote:
> > > > On 11.01.16 at 16:06, wrote:
> > On 1/11/16 8:24 AM, Jan Beulich wrote:
> > > Considering the size of the patch, the doubling of the
> > > identifier's
> > > length, and the fact that even Linux continues to use NR_CPUS
> > > I wonder w
>>> On 11.01.16 at 16:10, wrote:
> Jan Beulich writes:
> On 08.01.16 at 22:22, wrote:
>>> +config SCHED_CREDIT
>>> + bool "Credit scheduler support"
>>> + default y
>>
>> I continue to think that not making the primary scheduler configurable
>> would be the better solution to the problems
>>> On 11.01.16 at 15:58, wrote:
> On 11.01.2016 15:32, Jan Beulich wrote:
> On 11.01.16 at 15:06, wrote:
>>> On 13.11.2015 10:50, Ian Campbell wrote:
On Fri, 2015-11-13 at 12:04 +0300, Andrei Borzenkov wrote:
>> How do you express modules other than kernel+initrd in that
>> sche
On 11/01/16 14:19, Jan Beulich wrote:
On 09.01.16 at 15:33, wrote:
>> --- a/xen/common/spinlock.c
>> +++ b/xen/common/spinlock.c
>> @@ -246,7 +246,7 @@ int _spin_trylock_recursive(spinlock_t *lock)
>> unsigned int cpu = smp_processor_id();
>>
>> /* Don't allow overflow of recurse_
This series documents changes needed to support toeplitz hashing in a
backend, configurable by the frontend.
Patch #1 is a clean-up patch that clarifies the guest transmit and
receive side packet formats.
Patch #2 documents a new 'control ring' for passing bulk data between
frontend and backend.
Currently there is no documented wire format for guest receive-side
packets but the location of the 'wire format' comment block suggests
it is the same as transmit-side. This is almost true but there is a
subtle difference in the use of the 'size' field for the first fragment.
For clarity this pat
This patch documents a new shared ring between frontend and backend that
can be used to pass bulk out-of-band data, such as that required to
implement toeplitz hashing in the backend such that it is configurable by
the frontend (which is needed to support NDIS RSS for Windows guests).
The patch th
>>> On 11.01.16 at 16:06, wrote:
> On 1/11/16 8:24 AM, Jan Beulich wrote:
> On 09.01.16 at 00:17, wrote:
>>> This converts the usage of NR_CPUS / MAX_PHYS_CPUS to Kconfig as
>>> CONFIG_NR_CPUS.
>>
>> Considering the size of the patch, the doubling of the identifier's
>> length, and the fact
On Fri, Jan 08, 2016 at 12:49:07PM -0600, Doug Goldstein wrote:
[...]
> Ok so I'm at a loss what steps I need to take. I've submitted patches to
> put the config in /boot so that this check can be made but there's a
> disagreement if that's even necessary or not.
>
That's a bit unfortunate. :-(
Stefano Stabellini writes:
> Add the PV block backend, the Xen mapcache, and hw/i386/xen to the list
> of Xen related files maintained by me.
>
> Signed-off-by: Stefano Stabellini
Reviewed-by: Markus Armbruster
___
Xen-devel mailing list
Xen-devel@l
Jan Beulich writes:
On 08.01.16 at 22:22, wrote:
>> --- a/xen/common/Kconfig
>> +++ b/xen/common/Kconfig
>> @@ -51,4 +51,71 @@ config KEXEC
>>
>>If unsure, say Y.
>>
>> +# Enable schedulers
>> +menu "Schedulers"
>> +visible if EXPERT = "y"
>
> Does "visible if EXPERT" not suffic
On 1/11/16 8:24 AM, Jan Beulich wrote:
On 09.01.16 at 00:17, wrote:
>> This converts the usage of NR_CPUS / MAX_PHYS_CPUS to Kconfig as
>> CONFIG_NR_CPUS.
>
> Considering the size of the patch, the doubling of the identifier's
> length, and the fact that even Linux continues to use NR_CPUS
>
On 22/12/15 11:56, George Dunlap wrote:
> On 18/12/15 16:08, Malcolm Crossley wrote:
>>
>> +
>> +#ifndef NDEBUG
>> +#define PERCPU_RW_LOCK_UNLOCKED(owner) { RW_LOCK_UNLOCKED, 0, owner }
>> +static inline void _percpu_rwlock_owner_check(percpu_rwlock_t **per_cpudata,
>> +
On Tue, Dec 01, 2015 at 05:04:35PM +0100, Fabio Fantoni wrote:
> This patch adds basic spice support for pv domUs.
> The qemu parameters are the same as the hvm ones and they works.
> Therefore xl cfg parameters are the same as the hvm ones except that
> features not supported yet by pv domUs (vdag
On 11.01.2016 15:32, Jan Beulich wrote:
On 11.01.16 at 15:06, wrote:
>> On 13.11.2015 10:50, Ian Campbell wrote:
>>> On Fri, 2015-11-13 at 12:04 +0300, Andrei Borzenkov wrote:
> How do you express modules other than kernel+initrd in that
> scheme, without grub needing to be aware of a
On Mon, Jan 11, 2016 at 12:57:27AM +0530, Harmandeep Kaur wrote:
> Hi,
>
> I tried to modify and compile some of Xen 4.7's code
> (cloned from git clone git://xenbits.xen.org/xen.git)
> and even with a very minor change (patch included at last)
> my xen failed to boot. It stucks at black blank scr
>>> On 11.01.16 at 14:59, wrote:
> Currently, hypercalls issued from HVM userspace will unconditionally fail
> with -EPERM.
>
> This is inflexible, and a guest may wish to allow userspace to make
> hypercalls.
I thought previous discussion had made clear that routing these
through ioctls or alik
> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Andrew Cooper
> Sent: 11 January 2016 14:00
> To: Xen-devel
> Cc: Andrew Cooper; Stefano Stabellini; Ian Campbell; Jan Beulich
> Subject: [Xen-devel] [PATCH] x86/hvm: Allow
>>> On 11.01.16 at 15:06, wrote:
> On 13.11.2015 10:50, Ian Campbell wrote:
>> On Fri, 2015-11-13 at 12:04 +0300, Andrei Borzenkov wrote:
How do you express modules other than kernel+initrd in that
scheme, without grub needing to be aware of any new addition we
may find necessary go
Stefano Stabellini writes:
> On Thu, 17 Dec 2015, Markus Armbruster wrote:
>> Cc: Stefano Stabellini
>> Cc: xen-de...@lists.xensource.com
>> Signed-off-by: Markus Armbruster
>> ---
>> xen-hvm.c | 7 +++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/xen-hvm.c b/xen-hvm.c
>> index 3
flight 77722 qemu-upstream-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77722/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 9 debian-installfail REGR. vs. 63071
test-amd64-i386-
>>> On 09.01.16 at 00:17, wrote:
> This converts the usage of NR_CPUS / MAX_PHYS_CPUS to Kconfig as
> CONFIG_NR_CPUS.
Considering the size of the patch, the doubling of the identifier's
length, and the fact that even Linux continues to use NR_CPUS
I wonder whether we wouldn't be better of simply
>>> On 09.01.16 at 15:33, wrote:
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -246,7 +246,7 @@ int _spin_trylock_recursive(spinlock_t *lock)
> unsigned int cpu = smp_processor_id();
>
> /* Don't allow overflow of recurse_cpu field. */
> -BUILD_BUG_ON(NR_CPUS > 0
>>> On 09.01.16 at 14:43, wrote:
> On 08/01/2016 23:17, Doug Goldstein wrote:
>> Introduce an option where the user can modifiy the maximum number of
>> supported physical CPUs.
>>
>> CC: Ian Campbell
>> CC: Stefano Stabellini
>> CC: Keir Fraser
>> CC: Jan Beulich
>> CC: Andrew Cooper
>> Sign
On Thu, Jan 07, 2016 at 09:25:20PM -0500, Konrad Rzeszutek Wilk wrote:
> If the hypervisor is built with we will display it.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> v2: Include HAVE_*, use libxl_zalloc, s/rc/ret/
> ---
> tools/libxl/libxl.c | 24
> tools
>>> On 08.01.16 at 22:22, wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -51,4 +51,71 @@ config KEXEC
>
> If unsure, say Y.
>
> +# Enable schedulers
> +menu "Schedulers"
> + visible if EXPERT = "y"
Does "visible if EXPERT" not suffice here?
> +config SCHED_CRED
On 13.11.2015 10:50, Ian Campbell wrote:
> On Fri, 2015-11-13 at 12:04 +0300, Andrei Borzenkov wrote:
>>> How do you express modules other than kernel+initrd in that
>>> scheme, without grub needing to be aware of any new addition we
>>> may find necessary going forward?
>>>
>>
>> Are modules used
Currently, hypercalls issued from HVM userspace will unconditionally fail with
-EPERM.
This is inflexible, and a guest may wish to allow userspace to make
hypercalls.
Introduce HVMOP_set_hypercall_dpl which allows the guest to alter the
permissions check for hypercalls. It behaves exactly like t
>>> On 09.01.16 at 19:08, wrote:
> On 09/01/16 17:50, Jonathan Creekmore wrote:
>> However, if you would prefer me to remove the "If unsure" language
>> completely, I can do that. The text came in before the whole
>> CONFIG_EXPERT flag did.
>
> I would suggest dropping it (although you probably w
>>> On 10.01.16 at 20:42, wrote:
> On 12/21/15 09:10, Jan Beulich wrote:
> On 28.11.15 at 22:45, wrote:
>>> @@ -167,26 +168,65 @@ static int hvmemul_do_io(
>>> vio->io_req.state = STATE_IOREQ_NONE;
>>> break;
>>> case X86EMUL_UNHANDLEABLE:
>>> -{
>>> -struct
flight 77735 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77735/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 62702
Tests w
flight 77716 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77716/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 59254
test-amd64-i386-xl-qe
This run is configured for baseline tests only.
flight 38615 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38615/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 10 guest-start
flight 77717 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77717/
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-
Doug Goldstein writes ("[Xen-devel] [PATCH v2 2/2] xen: convert XSM_ENABLE to
Kconfig"):
> Converts the existing XSM_ENABLE flag from Config.mk to CONFIG_XSM
> within Kconfig. This also re-adds the dependency of CONFIG_FLASK on
> CONFIG_XSM.
Some version of these patches were applied to xen.git#s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.5-rc0-tag
xen: features and fixes for 4.5-rc0
- - Stolen ticks and PV wallclock support for arm/arm64.
- - Add grant copy ioctl to gntd
On 10/01/16 14:21, Michael S. Tsirkin wrote:
> drivers/xen/events/events_fifo.c uses rmb() to communicate with the
> other side.
>
> For guests compiled with CONFIG_SMP, smp_rmb would be sufficient, so
> rmb() here is only needed if a non-SMP guest runs on an SMP host.
>
> Switch to the virt_rmb
On Tue, Jan 05, 2016 at 12:09:30AM +, James Hogan wrote:
> Hi Michael,
>
> On Thu, Dec 31, 2015 at 09:08:22PM +0200, Michael S. Tsirkin wrote:
> > This defines __smp_xxx barriers for metag,
> > for use by virtualization.
> >
> > smp_xxx barriers are removed as they are
> > defined correctly b
Hi Michael,
On Mon, Jan 11, 2016 at 10:04 PM, Michael S. Tsirkin wrote:
> On Mon, Jan 11, 2016 at 12:59:25PM +0200, Michael S. Tsirkin wrote:
>> As part of memory barrier cleanup, this patchset
>> extends checkpatch to make it easier to stop
>> incorrect memory barrier usage.
>>
>> This replaces
On Mon, Jan 11, 2016 at 12:59:25PM +0200, Michael S. Tsirkin wrote:
> As part of memory barrier cleanup, this patchset
> extends checkpatch to make it easier to stop
> incorrect memory barrier usage.
>
> This replaces the checkpatch patches in my series
> arch: barrier cleanup + barriers for
On Mon, Jan 11, 2016 at 10:46:20AM +, Stefano Stabellini wrote:
> On Mon, 11 Jan 2016, Hao, Xudong wrote:
> > Stefano,
> >
> > Patch http://marc.info/?l=qemu-devel&m=145137863501079 don't works for qemu
> > at all, some conflict when git apply.
> > Patch http://marc.info/?l=qemu-devel&m=145
Add virt_ barriers to list of barriers to check for
presence of a comment.
Signed-off-by: Michael S. Tsirkin
---
scripts/checkpatch.pl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 25476c2..c7bf1aa 100755
--- a/scripts/c
Introduction of __smp barriers cleans up a bunch of duplicate code, but
it gives people an additional handle onto a "new" set of barriers - just
because they're prefixed with __* unfortunately doesn't stop anyone from
using it (as happened with other arch stuff before.)
Add a checkpatch test so it
SMP-only barriers were missing in checkpatch.pl
Refactor code slightly to make adding more variants easier.
Signed-off-by: Michael S. Tsirkin
---
scripts/checkpatch.pl | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/chec
As part of memory barrier cleanup, this patchset
extends checkpatch to make it easier to stop
incorrect memory barrier usage.
This replaces the checkpatch patches in my series
arch: barrier cleanup + barriers for virt
and will be included in the pull request including
the series.
changes
1 - 100 of 115 matches
Mail list logo
