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
> 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.
> 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
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.
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
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
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
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 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 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 Thu, 6 Apr 2017, Chris Patterson wrote:
> From: Chris Patterson
>
> Several Tegra hardware devices, and the Tegra device tree, expect
> the presence of a Tegra Legacy Interrupt Controller (LIC) in the hardware
> domain. Accordingly, we'll need to expose (most of) the LIC's registers
> to the h
On Thu, 6 Apr 2017, Chris Patterson wrote:
> From: "Chris Patterson"
>
> Tegra devices have a legacy interrupt controller (lic, or ictlr) that
> must be programmed in parallel with their primary GIC. For all intents
> and purposes, we treat these devices attached to this controller as
> connected
On Thu, 6 Apr 2017, Chris Patterson wrote:
> From: "Chris Patterson"
>
> Some common platforms (e.g. Tegra) have non-traditional IRQ controllers
> that must be programmed in addition to their primary GICs-- and which
> can come in unusual topologies. Device trees for targets that feature
> these
This run is configured for baseline tests only.
flight 71191 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71191/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d63ed30bb508f46ec304cf1431a67c8f9f2fe0bf
baseline v
On Thu, 6 Apr 2017, Chris Patterson wrote:
> From: Chris Patterson
>
> Tegra boards feature a NS16550-compatible serial mapped into the MMIO
> space. Add support for its use both as a full-featured serial port and
> as an earlyprintk driver.
>
> This patch adds a quirk for platforms, such as the
On 13/04/17 14:29, Julien Grall wrote:
Hi Julien,
>> 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
flight 107422 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107422/
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 REGR. vs.
106822
Tests whi
flight 107436 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107436/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 5 ker
flight 107425 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107425/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d63ed30bb508f46ec304cf1431a67c8f9f2fe0bf
baseline version:
ovmf f90c4fff00bee5f654ad9
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-xl-arndale
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git
The following commit:
commit 815dd18788fe0d41899f51b91d0560279cf16b0d
Author: Bart Van Assche
Date: Fri Jan 20 13:04:04 2017 -0800
treewide: Consolidate get_dma_ops() implementations
rearranges get_dma_ops in a way that xen_dma_ops are not returned when
running on Xen anymore, dev
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: boris.ostrov...@oracle.com
CC: jgr...@suse.com
CC: Juli
flight 107420 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107420/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 3 host-install(3)broken REGR. vs. 10739
flight 107418 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107418/
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
Tests which are faili
On 4/13/17 9:11 AM, 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). Multiboot protocol
>>> com
flight 107433 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107433/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 5 ker
In order to use "len" to check for xenbus_read errors properly, we need
to initialize len to 0 before passing it to xenbus_read.
Signed-off-by: Stefano Stabellini
CC: dan.carpen...@oracle.com
CC: jgr...@suse.com
CC: boris.ostrov...@oracle.com
CC: Eric Van Hensbergen
CC: Ron Minnich
CC: Latchesa
On April 13, 2017 4:41:03 AM EDT, 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:
>> > [...]
>> > >
>> > > .. Except that
On 13/04/17 07:07, Jan Beulich wrote:
> No matter that we emulate IRET for (guest) real more only right now, we
> should get its effect on (virtual) NMI delivery right. Note that we can
> simply check the other retire flags also in the !OKAY case, as the
> insn emulator now guarantees them to only
On Thu, 13 Apr 2017, Roger Pau Monné wrote:
> 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 R
On Thu, Apr 13, 2017 at 06:28:33PM +0200, Juergen Gross wrote:
> On 13/04/17 18:24, Greg KH wrote:
> > On Thu, Apr 13, 2017 at 04:49:49PM +0200, Juergen Gross wrote:
> >> Revert commit 72a9b186292 ("xen: Remove event channel notification
> >> through Xen PCI platform device") as the original analys
On 04/13/2017 11:46 AM, Jan Beulich wrote:
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
flight 107417 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107417/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107384
test-armhf-armhf-libvirt-raw 12
On 04/13/2017 11:41 AM, Jan Beulich wrote:
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 m
Dear community members,
today we created Xen 4.9 RC1 (see
https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01899.html)
== Subsequent RC's ==
We will release a new release candidate every week on Friday, until we declare
a release candidate as the final candidate and cut the Xe
flight 107430 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107430/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 5 ker
On 13/04/17 18:24, Greg KH wrote:
> On Thu, Apr 13, 2017 at 04:49:49PM +0200, Juergen Gross wrote:
>> 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 com
On Thu, Apr 13, 2017 at 04:49:49PM +0200, Juergen Gross wrote:
> 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 x
On 13/04/17 16:28, Jan Beulich wrote:
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
>>> On 03.04.17 at 18:50, wrote:
> Instead of scrubbing pages while holding heap lock we can mark
> buddy's head as being scrubbed and drop the lock temporarily.
> If someone (most likely alloc_heap_pages()) tries to access
> this chunk it will signal the scrubber to abort scrub by setting
> head'
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
>>> 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.
>>> 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 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 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 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
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: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,
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 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
>>> 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 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 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 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
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
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
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
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")
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
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
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
>
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 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
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
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
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:
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
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
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().
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
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
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
__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
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
>>> 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 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,
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 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
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 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_
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 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 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 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 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 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
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, 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
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 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
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: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
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
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
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
1 - 100 of 130 matches
Mail list logo
