flight 102318 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102318/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 102286
test-armhf-armhf-x
flight 102330 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102330/
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. 102292
test-amd64-i386-xl-qemuu-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Thursday, November 17, 2016 1:45 AM
>
> On 11/16/2016 12:34 PM, Andrew Cooper wrote:
> > On 16/11/16 17:34, Boris Ostrovsky wrote:
> >> On 11/16/2016 12:10 PM, Andrew Cooper wrote:
> >>> On 16/11/16 16:40, Boris Ostrovsky wrote:
>
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, November 16, 2016 8:32 PM
>
> core2_no_vpmu_ops exists solely to work around the default-leaking of
> CPUID/MSR
> values in Xen.
>
> With CPUID handling removed from arch_vpmu_ops, the RDMSR handling is the last
> remain
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, November 16, 2016 9:34 PM
>
> >>> On 16.11.16 at 14:01, wrote:
> > On 16/11/16 12:53, Jan Beulich wrote:
> > On 16.11.16 at 13:31, wrote:
> >>> This reduces the net complexity of CPUID handling by having all
> >>> adjustments
在 2016/11/16 18:23, Peter Zijlstra 写道:
On Wed, Nov 16, 2016 at 12:19:09PM +0800, Pan Xinhui wrote:
Hi, Peter.
I think we can avoid a function call in a simpler way. How about below
static inline bool vcpu_is_preempted(int cpu)
{
/* only set in pv case*/
if (pv_lock_ops
> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Wednesday, November 16, 2016 3:49 PM
>
> On 11/16/2016 09:22 AM, Tian, Kevin wrote:
> > Looks not working with APICv virtual interrupt delivery...
>
> It's only meant to work with "regular" injections (we'd like to be able
> to te
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, November 16, 2016 9:42 PM
>
> On 26/10/16 14:15, Andrew Cooper wrote:
> > The x86_segment enumeration matches hardware SReg encoding, which can be
> > used
> > to calculate the appropriate VMCS fields, rather than open co
flight 102322 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102322/
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. 102292
test-amd64-i386-xl-qemuu-
flight 102310 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102310/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909
test-amd64-amd64-
On 17/11/2016 00:00, Boris Ostrovsky wrote:
>> When we want to enable ACPI vcpu hotplug for HVM guests,
What do you mean by "when"? We *are* doing ACPI hotplug for HVM guests,
aren't we?
>>> Are we? If so, how?
>>>
>>> I don't see any toolstack or qemu code able to cope with APCI CPU
>>
>
> When we want to enable ACPI vcpu hotplug for HVM guests,
>>> What do you mean by "when"? We *are* doing ACPI hotplug for HVM guests,
>>> aren't we?
>> Are we? If so, how?
>>
>> I don't see any toolstack or qemu code able to cope with APCI CPU
>> hotplug. I can definitely see ACPI PCI hotplu
This run is configured for baseline tests only.
flight 68050 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68050/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub 10 guest-start
flight 102314 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102314/
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. 102292
test-amd64-i386-xl-qemuu-
All the different target_cmd_* end up calling tcmdex
which has the unfortunate side-effect of calling 'die' if
the SSH sessions results in any return code not zero.
That is fine, except for tests where we want to get a non-zero
return value.
This patch moves the: die "status $r" from tcmdex
to al
Signed-off-by: Konrad Rzeszutek Wilk
---
make-flight | 12
mfi-common | 9 +
2 files changed, 21 insertions(+)
diff --git a/make-flight b/make-flight
index d45a0e3..c2add66 100755
--- a/make-flight
+++ b/make-flight
@@ -485,6 +485,17 @@ do_xtf_tests () {
done
}
+do_l
Signed-off-by: Konrad Rzeszutek Wilk
---
sg-run-job | 5 +
1 file changed, 5 insertions(+)
diff --git a/sg-run-job b/sg-run-job
index c5cc3c6..7e326b9 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -421,6 +421,11 @@ proc run-job/test-xtf {} {
run-ts . = ts-xtf-run
}
+proc need-hosts/tes
There are 32 test-cases in there. Before we run
any of them we verify that the payload files are present
in /usr/lib/debug.
If so we go through all of the test-cases.
Signed-off-by: Konrad Rzeszutek Wilk
---
ts-livepatch | 102 +++
1 file
Livepatch compiles and works on x86/ARM{32|64} so we can
unconditionaly enable it.
Signed-off-by: Konrad Rzeszutek Wilk
---
ts-xen-build | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ts-xen-build b/ts-xen-build
index 4f1f71a..c567054 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -118,6
That come with the Xen git tree (see xen/test/).
Signed-off-by: Konrad Rzeszutek Wilk
---
ts-xen-build | 7 +++
1 file changed, 7 insertions(+)
diff --git a/ts-xen-build b/ts-xen-build
index 9843c2e..1b36b9c 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -170,6 +170,13 @@ END
Signed-off-by: Konrad Rzeszutek Wilk
---
ts-xen-build | 5 +
1 file changed, 5 insertions(+)
diff --git a/ts-xen-build b/ts-xen-build
index c567054..9843c2e 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -165,6 +165,11 @@ END
END
store_runvar("flaskpolicy", "xenpolicy-" . $xen_vers
Heya!
With this test-harness I am able to run the regressions tests on livepatches
on Xen 4.8. I only used the standalone tests. The incantations was:
To prep:
./sg-run-job build-amd64
./sg-run-job build-amd64-pvops
And then to run:
./sg-run-job test-amd64-amd64-livepatch
There are still some T
flight 102302 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102302/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 14 guest-stop fail REGR. vs. 102286
test-armhf-armhf-x
I will like to attend GMT -6.
Thanks,
Sameer
On 11/8/2016 5:19 AM, Julien Grall wrote:
Hi all,
I would like to start organizing a recurring community call to discuss
and sync-up on upcoming features for Xen ARM.
Example of features that could be discussed:
- Sharing co-processor between g
flight 102305 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102305/
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. 102292
test-amd64-i386-xl-qemuu-
This run is configured for baseline tests only.
flight 68051 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68051/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e242cdfb307a6dfe2c0f75c4719f5c1f6b418625
baseline v
flight 102308 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102308/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
Hi,
Try to use attached files as DTS. I didn't tested, but looks like there are
few missed nodes:
- hypervisor
- psci
I'm not sure, that Linux & Xen will correctly inter-works without them.
With the best regards,
Iurii Mykhalskyi
On Wed, Nov 16, 2016 at 7:23 PM, George John
wrote:
> Hi,
> I
On Fri, Nov 11, 2016 at 09:53:49AM -0700, Jan Beulich wrote:
> >>> On 29.10.16 at 10:59, wrote:
> > --- a/xen/arch/x86/domain_build.c
> > +++ b/xen/arch/x86/domain_build.c
> > @@ -191,10 +191,8 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain
> > *dom0)
> > }
> >
> > #ifdef CONFIG_SHADOW
v2 patch FYI. I have queued this in my for-4.9 branch, for merging when we
branch.
~Andrew
---%<---
This makes it more succinct and easier to read.
Before:
(XEN) H_CR3 = 0x00042a0ec000 CleanBits = 0
(XEN) CS: sel=0x0008, attr=0x029b, limit=0x, base=0x
(XEN) D
Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
NUMA balancing") set VM_IO flag to prevent grant maps from being
subjected to NUMA balancing.
It was discovered recently that this flag causes get_user_pages() to
always fail with -EFAULT.
check_vma_flags
__get_user_pages
__get
On 11/16/2016 12:34 PM, Andrew Cooper wrote:
> On 16/11/16 17:34, Boris Ostrovsky wrote:
>> On 11/16/2016 12:10 PM, Andrew Cooper wrote:
>>> On 16/11/16 16:40, Boris Ostrovsky wrote:
On 11/16/2016 07:31 AM, Andrew Cooper wrote:
> @@ -3700,6 +3701,14 @@ void hvm_cpuid(unsigned int input, un
On 16/11/16 17:34, Boris Ostrovsky wrote:
> On 11/16/2016 12:10 PM, Andrew Cooper wrote:
>> On 16/11/16 16:40, Boris Ostrovsky wrote:
>>> On 11/16/2016 07:31 AM, Andrew Cooper wrote:
@@ -3700,6 +3701,14 @@ void hvm_cpuid(unsigned int input, unsigned int
*eax, unsigned int *ebx,
>>
On 11/16/2016 12:10 PM, Andrew Cooper wrote:
> On 16/11/16 16:40, Boris Ostrovsky wrote:
>> On 11/16/2016 07:31 AM, Andrew Cooper wrote:
>>> @@ -3700,6 +3701,14 @@ void hvm_cpuid(unsigned int input, unsigned int
>>> *eax, unsigned int *ebx,
>>>
>>> *ebx &= hvm_featureset[FEATURESET_e8b]
flight 102290 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102290/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 9 debian-di-installfail REGR. vs. 101909
test-amd64-amd64-
Hi,
I just bumped in to some errors related to filesystem . The following is
the log. I am using xen 4.7.1 along with linux kernel 3.19.8 as Dom0
Starting kernel ...
- UART enabled -
- CPU booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registers -
- Turning on p
On 11/16/2016 10:48 AM, Boris Ostrovsky wrote:
On 11/16/2016 08:43 AM, Andrew Cooper wrote:
On 31/10/16 13:48, Andrew Cooper wrote:
This makes it more succinct and easier to read.
Before:
(XEN) H_CR3 = 0x00042a0ec000 CleanBits = 0
(XEN) CS: sel=0x0008, attr=0x029b, limit=0x, ba
On 16/11/16 17:02, Boris Ostrovsky wrote:
> Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
> NUMA balancing") set VM_IO flag to prevent grant maps from being
> subjected to NUMA balancing.
>
> It was discovered recently this this flag may cause page allocation
> failures wit
On Wed, Nov 16, 2016 at 07:09:01AM +0100, Juergen Gross wrote:
> On 15/11/16 01:11, Alex Thorlton wrote:
> > On systems with sufficiently large e820 tables, and several IOAPICs, it
> > is possible for the XENMEM_machine_memory_map callback (and its
> > counterpart, XENMEM_memory_map) to attempt to
On Tue, Nov 15, 2016 at 07:30:35AM +0100, Ingo Molnar wrote:
>
> * Alex Thorlton wrote:
>
> > On systems with sufficiently large e820 tables, and several IOAPICs, it
> > is possible for the XENMEM_machine_memory_map callback (and its
> > counterpart, XENMEM_memory_map) to attempt to return an e8
On 16/11/16 16:40, Boris Ostrovsky wrote:
> On 11/16/2016 07:31 AM, Andrew Cooper wrote:
>> @@ -3700,6 +3701,14 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
>> unsigned int *ebx,
>>
>> *ebx &= hvm_featureset[FEATURESET_e8b];
>> break;
>> +
>> +case 0x801c:
>
On 16/11/16 17:09, Boris Ostrovsky wrote:
> On 11/16/2016 12:04 PM, Andrew Cooper wrote:
>> On 16/11/16 16:27, Boris Ostrovsky wrote:
>>> On 11/16/2016 07:31 AM, Andrew Cooper wrote:
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index a542f4d..1f822ca 100644
--- a/xe
On 16/11/16 15:53, Jan Beulich wrote:
On 16.11.16 at 13:31, wrote:
>> @@ -961,13 +962,38 @@ int cpuid_hypervisor_leaves( uint32_t idx, uint32_t
>> sub_idx,
>> }
>> break;
>>
>> -case 4:
>> -if ( !has_hvm_container_domain(currd) )
>> +case 4: /* HVM hypervi
On 16/11/16 15:20, Jan Beulich wrote:
On 16.11.16 at 13:31, wrote:
>> @@ -3676,6 +3671,12 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
>> unsigned int *ebx,
>> if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
>> *edx &= ~cpufeat_mask(X86_FEAT
On 11/16/2016 12:04 PM, Andrew Cooper wrote:
> On 16/11/16 16:27, Boris Ostrovsky wrote:
>> On 11/16/2016 07:31 AM, Andrew Cooper wrote:
>>> diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
>>> index a542f4d..1f822ca 100644
>>> --- a/xen/arch/x86/cpu/vpmu.c
>>> +++ b/xen/arch/x86/cpu/
On 16/11/16 16:27, Boris Ostrovsky wrote:
> On 11/16/2016 07:31 AM, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
>> index a542f4d..1f822ca 100644
>> --- a/xen/arch/x86/cpu/vpmu.c
>> +++ b/xen/arch/x86/cpu/vpmu.c
>> @@ -136,9 +136,10 @@ int vpmu_do_msr(unsig
Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
NUMA balancing") set VM_IO flag to prevent grant maps from being
subjected to NUMA balancing.
It was discovered recently this this flag may cause page allocation
failures with the following stack:
check_vma_flags
__get_user_pag
On Wed, Nov 16, 2016 at 05:42:11PM +0100, Juergen Gross wrote:
> On 15/11/16 08:15, Jan Beulich wrote:
> On 15.11.16 at 07:33, wrote:
> >> On 15/11/16 01:11, Alex Thorlton wrote:
> >>> Hey everyone,
> >>>
> >>> We're having problems with large systems hitting a BUG in
> >>> xen_memory_setup,
On Fri, Nov 11, 2016 at 03:04:49AM -0700, Jan Beulich wrote:
> >>> On 10.11.16 at 18:21, wrote:
> > On Thu, Nov 10, 2016 at 04:20:34PM +0100, Roger Pau Monné wrote:
> >> > 0a:11.4 Ethernet controller: Intel Corporation 82576 Virtual Function
> >> > (rev 01)
> >> > Subsystem: Super Micro Co
On 11/16/2016 08:43 AM, Andrew Cooper wrote:
> On 31/10/16 13:48, Andrew Cooper wrote:
>> This makes it more succinct and easier to read.
>>
>> Before:
>> (XEN) H_CR3 = 0x00042a0ec000 CleanBits = 0
>> (XEN) CS: sel=0x0008, attr=0x029b, limit=0x,
>> base=0x
>> (XEN
On Thu, Nov 10, 2016 at 09:37:19AM -0700, Jan Beulich wrote:
> >>> On 10.11.16 at 11:39, wrote:
> > On Wed, Nov 09, 2016 at 01:45:17PM -0500, Konrad Rzeszutek Wilk wrote:
> >> On Wed, Nov 09, 2016 at 04:59:12PM +0100, Roger Pau Monné wrote:
> >> > PCI memory BARs
> >> > ---
> >> >
> >
On 15/11/16 08:15, Jan Beulich wrote:
On 15.11.16 at 07:33, wrote:
>> On 15/11/16 01:11, Alex Thorlton wrote:
>>> Hey everyone,
>>>
>>> We're having problems with large systems hitting a BUG in
>>> xen_memory_setup, due to extra e820 entries created in the
>>> XENMEM_machine_memory_map callba
On 11/16/2016 07:31 AM, Andrew Cooper wrote:
> @@ -3700,6 +3701,14 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
> unsigned int *ebx,
>
> *ebx &= hvm_featureset[FEATURESET_e8b];
> break;
> +
> +case 0x801c:
> +if ( !(v->arch.xcr0 & XSTATE_LWP) )
> +
On 11/16/2016 07:31 AM, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
> index a542f4d..1f822ca 100644
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -136,9 +136,10 @@ int vpmu_do_msr(unsigned int msr, uint64_t *msr_content,
> const
>>> On 16.11.16 at 13:31, wrote:
> @@ -961,13 +962,38 @@ int cpuid_hypervisor_leaves( uint32_t idx, uint32_t
> sub_idx,
> }
> break;
>
> -case 4:
> -if ( !has_hvm_container_domain(currd) )
> +case 4: /* HVM hypervisor leaf. */
> +if ( !has_hvm_container
>>> On 16.11.16 at 13:31, wrote:
> This reduces the net complexity of CPUID handling by having all adjustments in
> at the same place.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http
On Tue, Nov 15, 2016 at 09:09:18AM -0700, Jan Beulich wrote:
> >>> On 15.11.16 at 17:04, wrote:
> > There is no reason to build, for example, dsdt_pvh.asl for hvmloader. We
> > pass which DSDTs to build via DSDT_FILES parameter.
> >
> > If DSDT_FILES is empty all DSDTs for a particular architectu
> For example, take a look at PVCalls which is entirely based on data
> copies:
>
> http://marc.info/?l=xen-devel&m=147639616310487
>
>
> I have already shown that it performs better than netfront/netback on
> x86 in this blog post:
>
> https://blog.xenproject.org/2016/08/30/pv-calls-a-new-paravirt
>>> On 16.11.16 at 13:31, wrote:
> @@ -3676,6 +3671,12 @@ void hvm_cpuid(unsigned int input, unsigned int *eax,
> unsigned int *ebx,
> if ( !(hvm_pae_enabled(v) || hvm_long_mode_enabled(v)) )
> *edx &= ~cpufeat_mask(X86_FEATURE_PSE36);
> }
> +
> +/*
flight 102301 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102301/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf d67f14955a854474cf1a837a9bacf92bba15c152
baseline version:
xtf 83d31c3933d0c7155b10c7
Julien,
>> What we estimate now is a thin Dom0 without any drivers running with
>> ramdisk. All drivers would be moved to a special guest domain.
>
> You may want to give a look what has been done on x86 with the "Dedicated
> hardware domain".
I have to look at the stuff.
> Another solution, is r
On Wed, Nov 16, 2016 at 03:56:04AM -0700, Jan Beulich wrote:
> >>> On 16.11.16 at 11:51, wrote:
> > vmcb->nextrip can legitimately be less than vmcb->rip when execution wraps
> > back around to 0. Instead, complain if the reported length is greater than
> > 15
> > and use x86_decode_insn() as a
flight 102298 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102298/
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. 102292
test-amd64-i386-xl-qemuu-
On 16 November 2016 at 15:31, David Vrabel wrote:
> On 16/11/16 13:12, Volodymyr Babchuk wrote:
>> Hello David,
>>
>> I helped Oleksandr with parts of this protocol, so I want to address
>> some questions you asked.
>>
>> On 16 November 2016 at 12:38, David Vrabel wrote:
>>>
>>> Sound is not my a
Hello David,
I helped Oleksandr with parts of this protocol, so I want to address
some questions you asked.
On 16 November 2016 at 12:38, David Vrabel wrote:
>
> Sound is not my area of expertise but I have a few points that you may
> like to consider.
>
> 1. You can only say how many channels a
Am 16.11.2016 um 13:23 schrieb Christian Borntraeger:
No need to duplicate the same define everywhere. Since
the only user is stop-machine and the only provider is
s390, we can use a default implementation of cpu_relax_yield
in sched.h.
Suggested-by: Russell King
Signed-off-by: Christian Borntr
On 31/10/16 13:48, Andrew Cooper wrote:
> This makes it more succinct and easier to read.
>
> Before:
> (XEN) H_CR3 = 0x00042a0ec000 CleanBits = 0
> (XEN) CS: sel=0x0008, attr=0x029b, limit=0x, base=0x
> (XEN) DS: sel=0x0033, attr=0x0cf3, limit=0x, base=0x0
> So it looks like there could be an generic API to deal with
> these various operations.
Currently it is designed to be a generic API with platform
(coprocessor) specific hooks.
> And I think you are thinking to hook it up to the scheduler so that when a
> guest
> switches you can follow with t
On 26/10/16 14:15, Andrew Cooper wrote:
> The x86_segment enumeration matches hardware SReg encoding, which can be used
> to calculate the appropriate VMCS fields, rather than open coding every
> instance.
>
> This reduces the size of the switch statement, and the number of embedded BUG
> frames fr
>>> On 16.11.16 at 14:01, wrote:
> On 16/11/16 12:53, Jan Beulich wrote:
> On 16.11.16 at 13:31, wrote:
>>> This reduces the net complexity of CPUID handling by having all adjustments
>>> in
>>> at the same place. Remove the now-unused vpmu_do_cpuid() infrastructure.
>> I have to admit that
On 16/11/16 13:12, Volodymyr Babchuk wrote:
> Hello David,
>
> I helped Oleksandr with parts of this protocol, so I want to address
> some questions you asked.
>
> On 16 November 2016 at 12:38, David Vrabel wrote:
>>
>> Sound is not my area of expertise but I have a few points that you may
>> li
On 16/11/16 12:53, Jan Beulich wrote:
On 16.11.16 at 13:31, wrote:
>> This reduces the net complexity of CPUID handling by having all adjustments
>> in
>> at the same place. Remove the now-unused vpmu_do_cpuid() infrastructure.
> I have to admit that I'm not convinced this is a good idea at
flight 102296 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102296/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
Konrad Rzeszutek Wilk writes ("OSSTest, standalone, weird end of invocation."):
> I've my test machine, and I can run some of the standalone
> tests. But everytime I run any of the jobs I get:
Erk. Try this.
Ian.
diff --git a/tcl/JobDB-Standalone.tcl b/tcl/JobDB-Standalone.tcl
index 375e6ba..09
>>> On 16.11.16 at 13:31, wrote:
> core2_no_vpmu_ops exists solely to work around the default-leaking of
> CPUID/MSR
> values in Xen.
>
> With CPUID handling removed from arch_vpmu_ops, the RDMSR handling is the last
> remaining hook. Since core2_no_vpmu_ops's introduction in c/s 25250ed7 "vpmu
>>> On 16.11.16 at 13:31, wrote:
> This reduces the net complexity of CPUID handling by having all adjustments in
> at the same place. Remove the now-unused vpmu_do_cpuid() infrastructure.
I have to admit that I'm not convinced this is a good idea at this point,
due to the added redundancy. Iirc
This run is configured for baseline tests only.
flight 68049 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68049/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2adf689cb7c66f4790a7d0a9e7e99aad6ebee638
baseline v
flight 68048 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68048/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like
68018
test-amd64-
On 16/11/16 12:49, Jan Beulich wrote:
On 16.11.16 at 13:31, wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -183,6 +183,25 @@ int get_cpu_vendor(const char v[], enum get_cpu_vendor
>> mode)
>> return X86_VENDOR_UNKNOWN;
>> }
>>
>> +u8 get_cpu_family
On Mon, Nov 14, 2016 at 05:12:53PM -0500, Konrad Rzeszutek Wilk wrote:
> Instead of the scripts having to poke at various fields we can
> provide that functionality via the -S parameter.
>
> Returns 0 if the payload is loaded. Can be used in combination
> with -l or -p to get the state of the prop
>>> On 16.11.16 at 13:31, wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -183,6 +183,25 @@ int get_cpu_vendor(const char v[], enum get_cpu_vendor
> mode)
> return X86_VENDOR_UNKNOWN;
> }
>
> +u8 get_cpu_family(uint32_t raw, u8 *model, u8 *stepping)
> +{
>
On Wed, Nov 16, 2016 at 01:23:05PM +0100, Christian Borntraeger wrote:
> No need to duplicate the same define everywhere. Since
> the only user is stop-machine and the only provider is
> s390, we can use a default implementation of cpu_relax_yield
> in sched.h.
>
> Suggested-by: Russell King
> Si
AM> The situation is not as bad as having full-scope driver (which is
AM> implemented in some proprietary hypervisors), we only need to:
AM> 1. stop
AM> 2. flush registers
AM> 3. switch memory context <--- implemented by SMMU in ARM
AM> 4. restore registers
AM> 5. start
Well, we also need to take
This is some cleanup intended to ease the development of further development
work. There is no practical change from a guests point of view.
Andrew Cooper (6):
xen/x86: Add a helper to calculate family/model/stepping information
x86/vpmu: Move vpmu_do_cpuid() handling into {pv,hvm}_cpuid()
This reduces the net complexity of CPUID handling by having all adjustments in
at the same place. Remove the now-unused hvm_funcs.hypervisor_cpuid_leaf()
infrastructure.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86/hvm/hvm.c| 22 --
This reduces the net complexity of CPUID handling by having all adjustments in
at the same place.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/time.c| 36
xen/arch/x86/traps.c | 40 +---
And replace the existing opencoded calculations.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpu/common.c | 36 ++--
xen/arch/x86/domctl.c | 7 +--
xen/include/asm-x86/processor.h | 2 ++
3 files changed, 25 insertions(
core2_no_vpmu_ops exists solely to work around the default-leaking of CPUID/MSR
values in Xen.
With CPUID handling removed from arch_vpmu_ops, the RDMSR handling is the last
remaining hook. Since core2_no_vpmu_ops's introduction in c/s 25250ed7 "vpmu
intel: Add cpuid handling when vpmu disabled",
This reduces the net complexity of CPUID handling by having all adjustments in
at the same place. Remove the now-unused vpmu_do_cpuid() infrastructure.
This involves introducing a vpmu_enabled() predicate, and making the Intel
specific VPMU_CPU_HAS_* constants public.
Signed-off-by: Andrew Coope
This reduces the net complexity of CPUID handling by having all adjustments in
at the same place. Remove the now-unused hvm_funcs.cpuid_intercept
infrastructure.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
CC: Boris Ostrovsky
CC: Suravee Suthikulpanit
--
flight 102286 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102286/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail like 102258
test-amd64-i386-xl-qemuu-wi
On Tue, Nov 15, 2016 at 04:07:03PM -0500, Konrad Rzeszutek Wilk wrote:
> Hey Ian,
>
> I've my test machine, and I can run some of the standalone
> tests. But everytime I run any of the jobs I get:
>
> .. snip..
> 2016-11-16 00:07:55 Z setting xtfbuildjob=build-amd64-xtf
> 2016-11-16 00:07:55 Z lo
No need to duplicate the same define everywhere. Since
the only user is stop-machine and the only provider is
s390, we can use a default implementation of cpu_relax_yield
in sched.h.
Suggested-by: Russell King
Signed-off-by: Christian Borntraeger
---
arch/alpha/include/asm/processor.h | 1
On Wed, Nov 16, 2016 at 12:29:44PM +0100, Christian Borntraeger wrote:
> On 11/16/2016 11:23 AM, Peter Zijlstra wrote:
> > On Wed, Nov 16, 2016 at 12:19:09PM +0800, Pan Xinhui wrote:
> >> Hi, Peter.
> >>I think we can avoid a function call in a simpler way. How about below
> >>
> >> static inli
On 11/16/2016 11:23 AM, Peter Zijlstra wrote:
> On Wed, Nov 16, 2016 at 12:19:09PM +0800, Pan Xinhui wrote:
>> Hi, Peter.
>> I think we can avoid a function call in a simpler way. How about below
>>
>> static inline bool vcpu_is_preempted(int cpu)
>> {
>> /* only set in pv case*/
>>
flight 102292 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102292/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e242cdfb307a6dfe2c0f75c4719f5c1f6b418625
baseline version:
ovmf 2adf689cb7c66f4790a7d
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qcow2
testid debian-di-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.q
>>> On 16.11.16 at 11:51, wrote:
> vmcb->nextrip can legitimately be less than vmcb->rip when execution wraps
> back around to 0. Instead, complain if the reported length is greater than 15
> and use x86_decode_insn() as a fallback.
>
> While making changes here, fix two whitespace issues with t
vmcb->nextrip can legitimately be less than vmcb->rip when execution wraps
back around to 0. Instead, complain if the reported length is greater than 15
and use x86_decode_insn() as a fallback.
While making changes here, fix two whitespace issues with the case labels.
Signed-off-by: Andrew Coope
Sound is not my area of expertise but I have a few points that you may
like to consider.
1. You can only say how many channels a stream has, not what the
channels correspond to (e.g., "left", "right" for a 2 channel stereo
stream; or "left-front", "rear-right", etc. for a 6 channel 5.1 surround
s
1 - 100 of 105 matches
Mail list logo