Hao, Xudong would like to recall the message, "[Xen-devel] [PATCH v4]
igd-passthrough-i440FX: convert to realize()".
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
If hardware support memory protect externsion, expose this feature
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_cpufeature.h | 1 +
tools/libxc/xc_cpuid_x86.c | 6 ++
2 files changed, 7 insertions(+)
>>> 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 with the XSM default policy and with the dummy ones.
>> >>
>> >> And with
On Mon, Jan 11, 2016 at 04:52:10PM +0800, Liang Li wrote:
> If hardware support memory protect externsion, expose this feature
> 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
I will defer this to the x86 maintainers.
>>> On 08.01.16 at 17:58, wrote:
> On 1/8/16 10:49 AM, Jan Beulich wrote:
> On 08.01.16 at 17:30, wrote:
>>> So, based on the Kconfig setup and the linker ASSERT, there should be no
>>> way to have a default scheduler that is not in the build. I wish Kconfig
>>> allowed you to state that you
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.
- Mesa 11.1 has the virtio-gpu 3D driver (virgl galliumd3 / OpenGL).
Did anyone try
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, right?
I can boot up Linux VM with IGD pass-thr
On 11/01/16 09:05, Wei Liu wrote:
> On Mon, Jan 11, 2016 at 04:52:10PM +0800, Liang Li wrote:
>> If hardware support memory protect externsion, expose this feature
>> 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
> I
> On 11/01/16 09:05, Wei Liu wrote:
> > On Mon, Jan 11, 2016 at 04:52:10PM +0800, Liang Li wrote:
> >> If hardware support memory protect extension, expose this feature to
> >> guest by default. Users don't have to use a 'cpuid= ' option in
> >> config file to turn it on.
> >>
> >> Signed-off-by: L
Hi,
> I can boot up Linux VM with IGD pass-through with latest qemu (without
> any additional patch), guest run 3D "nexuiz" and get 180fps.
That is a pretty recent linux guest I assume?
Tried older kernels too, possibly even the old userspace xorg driver?
Do windows guest work as well?
cheers
Il 11/01/2016 10:47, Pasi Kärkkäinen ha scritto:
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.
- Mesa 11.1 has the virtio-gpu 3D d
On Sun, Jan 10, 2016 at 02:52:16PM -0800, Joe Perches wrote:
> On Mon, 2016-01-11 at 09:13 +1100, Julian Calaby wrote:
> > On Mon, Jan 11, 2016 at 6:31 AM, Michael S. Tsirkin wrote:
> > > Add virt_ barriers to list of barriers to check for
> > > presence of a comment.
> []
> > > diff --git a/scrip
Hi Michael,
On Mon, Jan 11, 2016 at 9:35 PM, Michael S. Tsirkin wrote:
> On Sun, Jan 10, 2016 at 02:52:16PM -0800, Joe Perches wrote:
>> On Mon, 2016-01-11 at 09:13 +1100, Julian Calaby wrote:
>> > On Mon, Jan 11, 2016 at 6:31 AM, Michael S. Tsirkin
>> > wrote:
>> > > Add virt_ barriers to list
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=145137863501079 is based on patch
> http://marc.info/?l=qemu-devel&m=1451721650106
On Mon, Jan 11, 2016 at 09:40:18PM +1100, Julian Calaby wrote:
> Hi Michael,
>
> On Mon, Jan 11, 2016 at 9:35 PM, Michael S. Tsirkin wrote:
> > On Sun, Jan 10, 2016 at 02:52:16PM -0800, Joe Perches wrote:
> >> On Mon, 2016-01-11 at 09:13 +1100, Julian Calaby wrote:
> >> > On Mon, Jan 11, 2016 at
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
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
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
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
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
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
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 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
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
-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
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
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-
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 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
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
>>> 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
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 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
>>> 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 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 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 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 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
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-
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
>>> 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
> -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 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
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.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 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 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 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
>
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
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
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. :-(
>>> 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
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
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 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.
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_
>>> 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 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 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: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 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 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 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 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.
> -
> -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
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
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
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
>>> 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
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
>>
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
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
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
>>> 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
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 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
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 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 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 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 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 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 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 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 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
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 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 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 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
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 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: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
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
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/
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
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
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/
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
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.
>
1 - 100 of 115 matches
Mail list logo
