On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> For some use cases when Xen framebuffer/input backend
> is not a part of Qemu it is required to disable it,
> because of conflicting access to input/display devices.
> Introduce additional configuration option
On 04/13/2017 05:04 PM, Stefano Stabellini wrote:
Now that __generic_dma_ops is a xen specific function, rename it to
xen_get_dma_ops. Change all the call sites appropriately.
Signed-off-by: Stefano Stabellini
CC: li...@armlinux.org.uk
CC: catalin.mari...@arm.com
CC: will.dea...@arm.com
CC: b
On Thu, Apr 13, 2017 at 04:11:25PM +0200, Daniel Kiper wrote:
> On Fri, Apr 07, 2017 at 05:23:33AM -0600, Jan Beulich wrote:
> > >>> On 21.02.17 at 20:19, wrote:
> > > Every multiboot protocol (regardless of version) compatible image must
> > > specify its load address (in ELF or multiboot header)
On Thu, Apr 13, 2017 at 08:48:48PM -0400, Boris Ostrovsky wrote:
>
>
> On 04/13/2017 05:04 PM, Stefano Stabellini wrote:
> > Now that __generic_dma_ops is a xen specific function, rename it to
> > xen_get_dma_ops. Change all the call sites appropriately.
> >
> > Signed-off-by: Stefano Stabellini
flight 107429 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107429/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 107176
Tests which are f
flight 107428 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107428/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
For some use cases when Xen framebuffer/input backend
is not a part of Qemu it is required to disable it,
because of conflicting access to input/display devices.
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, April 13, 2017 10:53 PM
>
> This is an optional feature and hence we should check for it before
> use.
>
> Signed-off-by: Jan Beulich
>
Reviewed-by: Kevin Tian
___
Xen-devel mailing l
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, April 13, 2017 10:54 PM
>
> This helps distingushing the call paths leading there.
>
> Signed-off-by: Jan Beulich
>
Reviewed-by: Kevin Tian
___
Xen-devel mailing list
Xen-devel@lists.
flight 107437 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107437/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
Regressions which are
Hi,
I submitted an application for this code review dashboard and
would love to keep working on the microtask once I get some
more info. :)
I also came up with a general idea of how the project might be
split up - any feedback on this would be welcome! I wrote:
"As said by Jesus, the big picture
Since the counter is unsigned, it's pointless/bogous to check
for if to be above zero.
Check that it is at least one before it's decremented, instead.
Spotted by Coverity.
Reported-by: Andrew Cooper
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Andrew Cooper
Cc: Julien Grall
---
J
This run is configured for baseline tests only.
flight 71187 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71187/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3 9 windows-i
flight 107393 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107393/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 107383
test-amd64-i386-xl-q
On 17-04-12 06:42:01, Jan Beulich wrote:
> >>> On 12.04.17 at 14:23, wrote:
> > On 17-04-12 03:09:56, Jan Beulich wrote:
> >> >>> On 12.04.17 at 07:53, wrote:
> >> > On 17-04-11 09:01:53, Jan Beulich wrote:
> >> >> >>> On 01.04.17 at 15:53, wrote:
> >> >> > +info->cos_ref[cos]--;
> >> >>
On 17-04-12 09:18:51, Jan Beulich wrote:
> >>> On 01.04.17 at 15:53, wrote:
> > @@ -304,10 +305,14 @@ static void cat_init_feature(const struct cpuid_leaf
> > *regs,
> > switch ( type )
> > {
> > case PSR_SOCKET_L3_CAT:
> > +case PSR_SOCKET_L2_CAT:
> > /* cos=0 is rese
flight 107400 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107400/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xend-qemut-winxpsp3 15 guest-localmigrate/x10 fail in 107365
REGR. vs. 106822
>>> On 13.04.17 at 10:12, wrote:
> On 17-04-12 09:18:51, Jan Beulich wrote:
>> >>> On 01.04.17 at 15:53, wrote:
>> > @@ -304,10 +305,14 @@ static void cat_init_feature(const struct cpuid_leaf
> *regs,
>> > switch ( type )
>> > {
>> > case PSR_SOCKET_L3_CAT:
>> > +case PSR_SOCK
Hi Wei,
>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> index a612d1f..fe7f795 100644
>> --- a/tools/libxl/libxl_types.idl
>> +++ b/tools/libxl/libxl_types.idl
>> @@ -105,6 +105,7 @@ libxl_console_type = Enumeration("console_type", [
>> (0, "UNKNOWN"),
>> (1,
Hi Wei,
>> /* --- pluggable kernel loader - */
>> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
>> index a7e839e..157381e 100644
>> --- a/tools/libxc/xc_dom_arm.c
>> +++ b/tools/libxc/xc_dom_arm.c
>> @@ -26,10 +26,11 @@
>> #include "xg_priv
On Thu, Apr 13, 2017 at 01:49:51PM +0530, Bhupinder Thakur wrote:
> Hi Wei,
>
> >> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> >> index a612d1f..fe7f795 100644
> >> --- a/tools/libxl/libxl_types.idl
> >> +++ b/tools/libxl/libxl_types.idl
> >> @@ -105,6 +105,7 @@ libxl_
On Wed, Apr 12, 2017 at 7:48 PM, Wei Liu wrote:
> On Mon, Apr 10, 2017 at 01:58:47PM +0300, Oleksandr Grytsov wrote:
>> Hi Ian,
>>
>> After internal discussion we think that putting positions and z-orders
>> of virtual connectors
>> to the Xen store and libxl configuration is not so good idea. Bec
On Wed, Apr 12, 2017 at 04:21:42PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Apr 12, 2017 at 04:46:33PM +0100, Wei Liu wrote:
> > On Mon, Apr 10, 2017 at 09:43:13AM -0400, Konrad Rzeszutek Wilk wrote:
> > [...]
> > >
> > > .. Except that we need some way of doing FLR and Pciback
> > > is the o
flight 71189 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71189/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-arm64 2 hosts-allocate broken never pass
build-arm64-pvops
On Thu, Apr 13, 2017 at 02:07:54PM +0530, Bhupinder Thakur wrote:
> Hi Wei,
>
>
> >> /* --- pluggable kernel loader - */
> >> diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> >> index a7e839e..157381e 100644
> >> --- a/tools/libxc/xc_dom_arm.
Hi Andrew,
On 10/04/17 13:14, Andrew Cooper wrote:
Since c/s 92cf67888a, x86_emulate_wrapper() asserts stricter behaviour about
the relationship between X86EMUL_EXCEPTION and ctxt.event_pending.
These removals should have been included in the aforementioned changeset, and
were only omitted due
Hi George,
On 12/04/17 09:25, George Dunlap wrote:
On 11/04/17 19:08, Praveen Kumar wrote:
The patch actually doesn't impact the functionality as such. This only replaces
bool_t with bool in credit2.
Signed-off-by: Praveen Kumar
Reviewed-by: George Dunlap
Julien, is this sort of thing all
Hi Jan,
On 12/04/17 13:44, Jan Beulich wrote:
On 12.04.17 at 07:35, wrote:
Fix two flaws in the patch (93358e8e VT-d: introduce update_irte to update
irte safely):
1. Expand a comment in update_irte() to make it clear that VT-d hardware
doesn't update IRTE and software can't update IRTE behind
Hi Wei,
On 12/04/17 15:54, Wei Liu wrote:
On Wed, Apr 12, 2017 at 09:19:34AM +0800, Luwei Kang wrote:
User can set max freq to specific cpu by
"xenpm set-scaling-maxfreq "
or set max freq to all cpu with default cpuid by
"xenpm set-scaling-maxfreq ".
Set max freq with defaule cpuid will cause
>>> On 13.04.17 at 10:11, wrote:
> On 17-04-12 06:42:01, Jan Beulich wrote:
>> >>> On 12.04.17 at 14:23, wrote:
>> > On 17-04-12 03:09:56, Jan Beulich wrote:
>> >> >>> On 12.04.17 at 07:53, wrote:
>> >> > On 17-04-11 09:01:53, Jan Beulich wrote:
>> >> >> >>> On 01.04.17 at 15:53, wrote:
>> >> >
Hi Dario,
On 13/04/17 08:49, Dario Faggioli wrote:
Since the counter is unsigned, it's pointless/bogous to check
for if to be above zero.
Check that it is at least one before it's decremented, instead.
Spotted by Coverity.
Do you have the Coverity-ID? :)
Reported-by: Andrew Cooper
Signed
On Thu, Apr 13, 2017 at 10:42:56AM +0100, Julien Grall wrote:
> Hi Dario,
>
> On 13/04/17 08:49, Dario Faggioli wrote:
> > Since the counter is unsigned, it's pointless/bogous to check
> > for if to be above zero.
> >
> > Check that it is at least one before it's decremented, instead.
> >
> > Sp
Hi Wei,
On 12 April 2017 at 22:03, Wei Liu wrote:
> On Mon, Apr 03, 2017 at 03:14:30PM +0530, Bhupinder Thakur wrote:
>> Modify the domain structure to to make console specific fields as an array
>> indexed
>> by the console type. Two console types are defined - PV and VCON.
>
> Why? Can you hav
On Thu, 2017-04-13 at 10:42 +0100, Julien Grall wrote:
> Hi Dario,
>
> On 13/04/17 08:49, Dario Faggioli wrote:
> > Since the counter is unsigned, it's pointless/bogous to check
> > for if to be above zero.
> >
> > Check that it is at least one before it's decremented, instead.
> >
> > Spotted b
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the x2apic feature is indicated as not
being present by special casing the related cpuid leaf.
Instead of delivering fake cpuid values clear the cpu capability bit
for x2apic instead.
Signed-off-by: Juer
Xen doesn't support DCA (direct cache access) for pv domains. Clear
the corresponding capability indicator.
Signed-off-by: Juergen Gross
---
arch/x86/xen/enlighten_pv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 6dc922e3848
There is no need to set the same capabilities for each cpu
individually. This can easily be done for all cpus when starting the
kernel.
Signed-off-by: Juergen Gross
---
arch/x86/xen/enlighten_pv.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/xen/enl
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the acc feature (thermal monitoring)
is indicated as not being present by special casing the related
cpuid leaf.
Instead of delivering fake cpuid values clear the cpu capability bit
for acc instead.
Sign
There is no user of x86_hyper->set_cpu_features() any more. Remove it.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Signed-off-by: Juergen Gross
---
arch/x86/include/asm/hypervisor.h | 5 -
arch/x86/kernel/cpu/common.c | 1 -
arch/x86/kernel/cpu/hyperv
Reduce special casing of xen_cpuid() by using cpu capabilities instead
of faked cpuid nodes.
This cleanup enables us remove the hypervisor specific set_cpu_features
callback as the same effect can be reached via
setup_[clear|force]_cpu_cap().
Removing the rest faked nodes from xen_cpuid() require
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the acpi feature is indicated as not
being present by special casing the related cpuid leaf in case we
are not the initial domain.
Instead of delivering fake cpuid values clear the cpu capability bit
for
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the mwait feature is indicated to be
present or not by special casing the related cpuid leaf.
Instead of delivering fake cpuid values use the cpu capability bit
for mwait instead.
Signed-off-by: Juergen
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the xsave feature availability is
indicated by special casing the related cpuid leaf.
Instead of delivering fake cpuid values set or clear the cpu
capability bits for xsave instead.
Signed-off-by: Juerge
There is no need to set the same capabilities for each cpu
individually. This can be done for all cpus in platform initialization.
Cc: Alok Kataria
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Juergen
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the mtrr feature is indicated as not
being present by special casing the related cpuid leaf.
Instead of delivering fake cpuid values clear the cpu capability bit
for mtrr instead.
Signed-off-by: Juergen
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the aperf/mperf feature is indicated
as not being present by special casing the related cpuid leaf.
Instead of delivering fake cpuid values clear the cpu capability bit
for aperf/mperf instead.
Signed-of
On 13/04/17 11:00, Dario Faggioli wrote:
> On Thu, 2017-04-13 at 10:42 +0100, Julien Grall wrote:
>> Hi Dario,
>>
>> On 13/04/17 08:49, Dario Faggioli wrote:
>>> Since the counter is unsigned, it's pointless/bogous to check
>>> for if to be above zero.
>>>
>>> Check that it is at least one before i
On 04/12/2017 08:11 PM, Tamas K Lengyel wrote:
>
>
> On Mon, Apr 10, 2017 at 3:44 AM, Razvan Cojocaru
> mailto:rcojoc...@bitdefender.com>> wrote:
>
> This patch adds support for testing instruction emulation when
> required by the vm_event reply sent for MEM_ACCESS events. To this
>
On 13/04/17 11:11, Juergen Gross wrote:
> @@ -281,22 +274,19 @@ static bool __init xen_check_mwait(void)
> return false;
> #endif
> }
> -static void __init xen_init_cpuid_mask(void)
> +
> +static bool __init xen_check_xsave(void)
> {
> - unsigned int ax, bx, cx, dx;
> - unsigned in
Hi all,
Xen 4.9 RC1 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.9.0-rc1.2
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.9.0-rc1.2/xen-4.9.0-rc1.2.tar.gz
And the signature is at:
https://downloads.xenproje
On Thu, 2017-04-13 at 12:11 +0200, Juergen Gross wrote:
> There is no need to set the same capabilities for each cpu
> individually. This can be done for all cpus in platform initialization.
Looks reasonable to me.
Acked-by: Alok Kataria
Thanks,
Alok
>
> Cc: Alok Kataria
> Cc: Thomas Gleixne
User can set max freq to specific cpu by
"xenpm set-scaling-maxfreq [cpuid] "
or set max freq to all cpu with default cpuid by
"xenpm set-scaling-maxfreq ".
Set max freq with default cpuid will cause
segmentation fault after commit id d4906b5d05.
This patch will fix this issue and add ability
to s
On Thu, Apr 13, 2017 at 10:41:06AM +0100, Julien Grall wrote:
> Hi Wei,
>
> On 12/04/17 15:54, Wei Liu wrote:
> > On Wed, Apr 12, 2017 at 09:19:34AM +0800, Luwei Kang wrote:
> > > User can set max freq to specific cpu by
> > > "xenpm set-scaling-maxfreq "
> > > or set max freq to all cpu with def
On 17-04-13 03:41:44, Jan Beulich wrote:
> >>> On 13.04.17 at 10:11, wrote:
> > On 17-04-12 06:42:01, Jan Beulich wrote:
> >> >>> On 12.04.17 at 14:23, wrote:
> >> > On 17-04-12 03:09:56, Jan Beulich wrote:
> >> >> >>> On 12.04.17 at 07:53, wrote:
> >> >> > On 17-04-11 09:01:53, Jan Beulich wrot
>>> On 13.04.17 at 12:49, wrote:
> On 17-04-13 03:41:44, Jan Beulich wrote:
>> >>> On 13.04.17 at 10:11, wrote:
>> > On 17-04-12 06:42:01, Jan Beulich wrote:
>> >> >>> On 12.04.17 at 14:23, wrote:
>> >> > On 17-04-12 03:09:56, Jan Beulich wrote:
>> >> >> >>> On 12.04.17 at 07:53, wrote:
>> >> >
On 17-04-13 04:58:06, Jan Beulich wrote:
> >>> On 13.04.17 at 12:49, wrote:
> > On 17-04-13 03:41:44, Jan Beulich wrote:
> >> >>> On 13.04.17 at 10:11, wrote:
> >> > On 17-04-12 06:42:01, Jan Beulich wrote:
> >> >> >>> On 12.04.17 at 14:23, wrote:
> >> >> > On 17-04-12 03:09:56, Jan Beulich wrot
On Thu, Apr 13, 2017 at 09:41:03AM +0100, Wei Liu wrote:
> On Wed, Apr 12, 2017 at 04:21:42PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Wed, Apr 12, 2017 at 04:46:33PM +0100, Wei Liu wrote:
> > > On Mon, Apr 10, 2017 at 09:43:13AM -0400, Konrad Rzeszutek Wilk wrote:
> > > [...]
> > > >
> > > > ..
On 17-04-13 19:11:54, Yi Sun wrote:
> On 17-04-13 04:58:06, Jan Beulich wrote:
> > >>> On 13.04.17 at 12:49, wrote:
> > > On 17-04-13 03:41:44, Jan Beulich wrote:
> > >> >>> On 13.04.17 at 10:11, wrote:
> > >> > On 17-04-12 06:42:01, Jan Beulich wrote:
> > >> >> >>> On 12.04.17 at 14:23, wrote:
>>> On 13.04.17 at 13:11, wrote:
> On 17-04-13 04:58:06, Jan Beulich wrote:
>> >>> On 13.04.17 at 12:49, wrote:
>> > How about a per socket array like this:
>> > uint32_t domain_switch[1024];
>> >
>> > Every bit represents a domain id. Then, we can handle this case as below:
>> > 1. In 'psr_cpu_
From: Oleksandr Andrushchenko
Xen input para-virtual protocol defines string constants
used by both back and frontend. Use those instead of
explicit strings in the frontend driver.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/input/misc/xen-kbdfront.c | 22 +-
1 file
From: Oleksandr Andrushchenko
Hi, all!
This patch series updates existing Xen vkbd frontend driver
to use string constants from the corresponding IO protocol
(kbdif.h) and adds support for virtual multi-touch input device.
This has been tested on a guest running Weston.
This patch series depen
From: Oleksandr Andrushchenko
Extend xen_kbdfront to provide multi-touch support
to unprivileged domains.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/input/misc/xen-kbdfront.c | 142 +-
1 file changed, 140 insertions(+), 2 deletions(-)
diff --git a/d
On Thu, Apr 13, 2017 at 06:44:28PM +0800, Luwei Kang wrote:
> User can set max freq to specific cpu by
> "xenpm set-scaling-maxfreq [cpuid] "
> or set max freq to all cpu with default cpuid by
> "xenpm set-scaling-maxfreq ".
>
> Set max freq with default cpuid will cause
> segmentation fault after
flight 107412 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107412/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f90c4fff00bee5f654ad93afd0f74b99050960de
baseline version:
ovmf 36a0d5cab8c9a6ad628ca
On 17-04-13 05:31:41, Jan Beulich wrote:
> >>> On 13.04.17 at 13:11, wrote:
> > On 17-04-13 04:58:06, Jan Beulich wrote:
> >> >>> On 13.04.17 at 12:49, wrote:
> >> > How about a per socket array like this:
> >> > uint32_t domain_switch[1024];
> >> >
> >> > Every bit represents a domain id. Then,
>>> On 13.04.17 at 13:44, wrote:
> On 17-04-13 05:31:41, Jan Beulich wrote:
>> >>> On 13.04.17 at 13:11, wrote:
>> > On 17-04-13 04:58:06, Jan Beulich wrote:
>> >> >>> On 13.04.17 at 12:49, wrote:
>> >> > How about a per socket array like this:
>> >> > uint32_t domain_switch[1024];
>> >> >
>> >
On Sun, 2017-04-09 at 21:50 -0700, Heather Booker wrote:
> Hi Jesus,
>
> While using the Elasticsearch python library
> (https://elasticsearch-py.readthedocs.io/en/master/) to add mbox
> messages to an index, I would get a UnicodeEncodeError:
> "'utf-8' codec can't encode character '\udca0' in pos
__sorry for the noise, please ignore this patch__
On April 13, 2017 11:45 AM, Quan Xu wrote:
>On April 13, 2017 3:35 AM, Chao Gao wrote:
>>On Thu, Apr 13, 2017 at 02:20:23AM +, Xuquan (Quan Xu) wrote:
>>>From 946e7589e5a875574c7567a91943d47c38218a6f Mon Sep 17
>>00:00:00 2001
>>>From: Quan Xu
Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display
device driver interface"):
> After internal discussion we think that putting positions and
> z-orders of virtual connectors to the Xen store and libxl
> configuration is not so good idea. Because their composition depe
Revert commit 72a9b186292 ("xen: Remove event channel notification
through Xen PCI platform device") as the original analysis was wrong
that all the removed code isn't in use any more.
It is still necessary for old Xen versions (< 4.0) and for being able
to run the Linux kernel as dom0 in a nested
On 07/04/17 18:34, Andre Przywara wrote:
Hello!
Hi Andre,
The development of the ARM ITS emulation support has taken more time
than anticipated and I won't be able to address and fix all outstanding
comments until the official code freeze date.
However the first part of the series is in a go
On 04/13/2017 06:11 AM, Juergen Gross wrote:
> Reduce special casing of xen_cpuid() by using cpu capabilities instead
> of faked cpuid nodes.
>
> This cleanup enables us remove the hypervisor specific set_cpu_features
> callback as the same effect can be reached via
> setup_[clear|force]_cpu_cap().
flight 107406 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107406/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
This run is configured for baseline tests only.
flight 71190 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71190/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f90c4fff00bee5f654ad93afd0f74b99050960de
baseline v
It is a good news and I hope Xen experts thinking about beginners like me. Xen
is great but have some problems in documenting and easy to use. I hope to see
this book on Xen Project website soon.
Thank you Xen team.
On Wed, 4/12/17, Lars Kurth wrote:
flight 107409 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107409/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 107176
Tests which are f
On 13/04/17 08:49, Dario Faggioli wrote:
> Since the counter is unsigned, it's pointless/bogous to check
> for if to be above zero.
>
> Check that it is at least one before it's decremented, instead.
>
> Spotted by Coverity.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Dario Faggioli
Revie
On Fri, Apr 07, 2017 at 05:23:33AM -0600, Jan Beulich wrote:
> >>> On 21.02.17 at 20:19, wrote:
> > Every multiboot protocol (regardless of version) compatible image must
> > specify its load address (in ELF or multiboot header). Multiboot protocol
> > compatible loader have to load image at speci
In a release build modern gcc validly complains about "pin" possibly
being uninitialized in vioapic_irq_positive_edge().
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -421,7 +421,11 @@ void vioapic_irq_positive_edge(struct do
struct hvm_vioa
On 13/04/17 15:29, Jan Beulich wrote:
> In a release build modern gcc validly complains about "pin" possibly
> being uninitialized in vioapic_irq_positive_edge().
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
>
> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
>
On 13/04/17 15:37, Andrew Cooper wrote:
On 13/04/17 15:29, Jan Beulich wrote:
In a release build modern gcc validly complains about "pin" possibly
being uninitialized in vioapic_irq_positive_edge().
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Release-acked-by: Julien Grall
C
Patch 1 brings recently added code in line with what we did switch
other code to during this dev cycle. Patch 2 is at least a latent bug fix.
Patch 3 is merely improving debuggability, so other than the first two
I'm not sure it qualifies for 4.9.
This is all fallout from re-basing my UMIP emulati
Revert commit 72a9b186292 ("xen: Remove event channel notification
through Xen PCI platform device") as the original analysis was wrong
that all the removed code isn't in use any more. As commit da72ff5bfcb0
("partially revert xen: Remove event channel notification through Xen
PCI platform device")
While I did review d0a699a389 ("x86/monitor: add support for descriptor
access events") it didn't really occur to me that somone could be this
blunt and add unguarded emulation again just a few weeks after we
guarded all special purpose emulator invocations. Fix this.
Signed-off-by: Jan Beulich
This is an optional feature and hence we should check for it before
use.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -866,7 +866,7 @@ static void svm_set_rdtsc_exiting(struct
vmcb_set_general2_intercepts(vmcb, general2_intercepts);
}
-s
This helps distingushing the call paths leading there.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2033,7 +2033,7 @@ int hvm_emulate_one_mmio(unsigned long m
switch ( rc )
{
case X86EMUL_UNHANDLEABLE:
-hvm_dump_emulation
On 04/13/2017 05:53 PM, Jan Beulich wrote:
> This is an optional feature and hence we should check for it before
> use.
>
> Signed-off-by: Jan Beulich
Acked-by: Razvan Cojocaru
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https
On 13/04/17 15:51, Jan Beulich wrote:
> While I did review d0a699a389 ("x86/monitor: add support for descriptor
> access events") it didn't really occur to me that somone could be this
> blunt and add unguarded emulation again just a few weeks after we
> guarded all special purpose emulator invocat
On 04/13/2017 10:54 AM, Jan Beulich wrote:
> This helps distingushing the call paths leading there.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 11.04.17 at 09:54, wrote:
> clang gcc-compat warnings can wrongly fire when certain constructions are
> used,
> at least the following flow:
>
> switch ( ... )
> {
> case ...:
> while ( ({ int x; switch ( foo ) { case 1: x = 1; break; } x }) )
> {
> ...
>
> Will cause cla
On Thu, Apr 13, 2017 at 06:44:28PM +0800, Luwei Kang wrote:
> User can set max freq to specific cpu by
> "xenpm set-scaling-maxfreq [cpuid] "
> or set max freq to all cpu with default cpuid by
> "xenpm set-scaling-maxfreq ".
>
> Set max freq with default cpuid will cause
> segmentation fault after
Hi,
On 13/04/17 16:19, Wei Liu wrote:
On Thu, Apr 13, 2017 at 06:44:28PM +0800, Luwei Kang wrote:
User can set max freq to specific cpu by
"xenpm set-scaling-maxfreq [cpuid] "
or set max freq to all cpu with default cpuid by
"xenpm set-scaling-maxfreq ".
Set max freq with default cpuid will ca
On 13/04/17 15:53, Jan Beulich wrote:
> @@ -223,9 +223,15 @@ int arch_monitor_domctl_event(struct dom
> ad->monitor.descriptor_access_enabled = requested_status;
>
> for_each_vcpu ( d, v )
> -hvm_funcs.set_descriptor_access_exiting(v, requested_status);
> +{
Hi Jan,
On 13/04/17 16:11, Jan Beulich wrote:
On 11.04.17 at 09:54, wrote:
clang gcc-compat warnings can wrongly fire when certain constructions are used,
at least the following flow:
switch ( ... )
{
case ...:
while ( ({ int x; switch ( foo ) { case 1: x = 1; break; } x }) )
{
On 13/04/17 15:54, Jan Beulich wrote:
> This helps distingushing the call paths leading there.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 13.04.17 at 16:59, wrote:
> On 13/04/17 15:51, Jan Beulich wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3598,6 +3598,28 @@ gp_fault:
>> return X86EMUL_EXCEPTION;
>> }
>>
>> +static bool is_sysdesc_access(const struct x86_emulate_state *state,
>> +
>>> On 13.04.17 at 17:16, wrote:
> On 13/04/17 15:53, Jan Beulich wrote:
>> @@ -223,9 +223,15 @@ int arch_monitor_domctl_event(struct dom
>> ad->monitor.descriptor_access_enabled = requested_status;
>>
>> for_each_vcpu ( d, v )
>> -hvm_funcs.set_descriptor_access_ex
>>> On 03.04.17 at 18:50, wrote:
> Signed-off-by: Boris Ostrovsky
To be honest, without a proper description and with an apparently
not really well formed title I don't want to start guessing what the
patch intends, and whether the changes done match that intention.
I guess this should really ha
>>> On 03.04.17 at 18:50, wrote:
> While waiting for a lock we may want to periodically run some
> code. We could use spin_trylock() but since it doesn't take lock
> ticket it may take a long time until the lock is taken.
>
> Add spin_lock_cb() that allows us to execute a callback while waiting.
Hi all,
I created https://wiki.xenproject.org/wiki/Xen_4.9_RC_test_instructions - this
needs checking and addition of specific stuff that you want people to test
I updated https://wiki.xenproject.org/wiki/Xen_Project_Test_Days
Regards
Lars
> On 13 Apr 2017, at 11:38, Julien Grall wrote:
>
> Hi
1 - 100 of 130 matches
Mail list logo
