flight 123150 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123150/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
test-amd64-amd64-xl-pvhv2-amd 7 xen-boot
flight 123187 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123187/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7dc7c7435e9030ad07ad7bc7d136a3997bd0b182
baseline version:
ovmf 77ca824c652443bdf3eda
This run is configured for baseline tests only.
flight 74744 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74744/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-build
flight 123147 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123147/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt 6 xen-install fail in 123073 pass in 123147
test-armhf-armhf-xl 7 xe
Hi Stefano,
Thank you very much for your fixes. It seems that you've addressed all
the issues during the last round of reviews.
I'm sorry for my off-and-on contribution time, which has largely
delayed the process of merging the patch set.
Please tell me if you need anything from me.
Cheers,
Zhong
On 25/05/2018 21:51, Stefano Stabellini wrote:
> On Wed, 23 May 2018, Julien Grall wrote:
>> Hi,
>>
>> On 05/23/2018 10:57 PM, Stefano Stabellini wrote:
>>> On Tue, 22 May 2018, Julien Grall wrote:
As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
mechanism for detec
On Fri, 25 May 2018, Julien Grall wrote:
> On Fri, 25 May 2018, 22:54 Stefano Stabellini, wrote:
> You might want to CC Konrad next time on this patch
>
>
> May I ask why? This code falls under Arm maintainership.
I know, but I appreciate his input if he has time for it
>
>
> On
flight 123144 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123144/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt 6 xen-install fail in 122971 pass in 123144
test-amd64-i386-xl-qemuu-debi
On Fri, 25 May 2018, 22:54 Stefano Stabellini,
wrote:
> You might want to CC Konrad next time on this patch
>
May I ask why? This code falls under Arm maintainership.
Cheers,
> On Tue, 22 May 2018, Julien Grall wrote:
> > This is part of XSA-263.
> >
> > Signed-off-by: Julien Grall
> >
> > -
On Wed, 23 May 2018, Julien Grall wrote:
> Hi,
>
> On 05/23/2018 10:57 PM, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > As for Spectre variant-2, we rely on SMCCC 1.1 to provide the discovery
> > > mechanism for detecting the SSBD mitigation.
> > >
> > > A new capa
You might want to CC Konrad next time on this patch
On Tue, 22 May 2018, Julien Grall wrote:
> This is part of XSA-263.
>
> Signed-off-by: Julien Grall
>
> ---
> I am aware of the missing commit message here. I wanted to send the
> series on the ML to get some feedback first.
> ---
> x
On Tue, 22 May 2018, Julien Grall wrote:
> A stack is allocated per vCPU to be used by Xen. The allocation is done
> with alloc_xenheap_pages that does not zero the memory returned. However
> the top of the stack is containing information that will be used to
> store the initial state of the vCPU (
On Tue, 22 May 2018, Julien Grall wrote:
> This is based on the Linux commit dea5e2a4c5bc "arm64: alternatives: Add
> dynamic patching feature" written by Marc Zyngier:
>
> We've so far relied on a patching infrastructure that only gave us
> a single alternative, without any way to provide
On Thu, 24 May 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 24/05/18 01:40, Stefano Stabellini wrote:
> > On Wed, 23 May 2018, Stefano Stabellini wrote:
> > > On Tue, 22 May 2018, Julien Grall wrote:
> > > > In order to offer ARCH_WORKAROUND_2 support to guests, we need to track
> > > > the
> >
On Thu, 24 May 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 23/05/18 23:34, Stefano Stabellini wrote:
> > On Tue, 22 May 2018, Julien Grall wrote:
> > > On a system where the firmware implements ARCH_WORKAROUND_2, it may be
> > > useful to either permanently enable or disable the workaround for
On Tue, 22 May 2018, Julien Grall wrote:
> The function ARM_SMCCC_ARCH_WORKAROUND_2 will be called by the guest for
> enabling/disabling the ssbd mitigation. So we want the handling to
> be as fast as possible.
>
> The new sequence will forward guest's ARCH_WORKAROUND_2 call to EL3 and
> also trac
flight 123135 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123135/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16
guest-localmigrate/x10 fail REGR. vs. 12
On 05/25/2018 08:38 AM, Razvan Cojocaru wrote:
> This patch mirrors the VMX code that doesn't allow
> vmx_disable_intercept_for_msr()
vmx_clear_msr_intercept() ?
> to clear interception of MSRs that
> an introspection agent is trying to monitor.
>
> Signed-off-by: Razvan Cojocaru
With that fix
On Fri, May 25, 2018 at 03:44:53PM +0100, Ian Jackson wrote:
> Linux 4.9 is getting a bit long in the tooth. 4.14 is an LTS branch
> and the osstest-tested version seems reasonably good. I ran a special
> report[1] to see what to expect and it reported no regressions.
>
> Accordingly I am going
flight 123129 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123129/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim broken
test-amd64-amd64-xl-qemut-debianhvm-amd64-x
Schedule for our Annual Developer and Design Summit
We are excited to announce the program and speakers for the Xen Project
Developer and Design Summit (https://www.lfasiallc.com/events/xensummit2018/).
The summit brings together developers, engineers, and Xen Project power users
for in-person
flight 74743 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74743/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like
74725
baseline version:
fl
On Fri, May 25, 2018 at 2:14 AM Pavel Machek wrote:
> On Thu 2018-05-24 09:35:42, Thomas Garnier wrote:
> > On Thu, May 24, 2018 at 4:03 AM Pavel Machek wrote:
> >
> > > On Wed 2018-05-23 12:54:03, Thomas Garnier wrote:
> > > > Change the assembly code to use only relative references of symbols
In 32-bit kernel builds, we cannot cast between a pointer and a 64-bit
type:
In file included from drivers/gpu/drm/xen/xen_drm_front_cfg.c:18:
drivers/gpu/drm/xen/xen_drm_front.h: In function 'xen_drm_front_fb_to_cookie':
drivers/gpu/drm/xen/xen_drm_front.h:129:9: error: cast from pointer to integ
Olaf Hering writes ("Re: [Xen-devel] [PATCH for-4.11] tools: set DEBUG_DIR from
configure"):
> On Tue, Mar 27, Roger Pau Monne wrote:
>
> > Allow the path to be set from a configure command line option.
>
> Please backport 641f9ce2fa to 4.10 ASAP. See
> https://lists.xenproject.org/archives/html
>>> On 25.05.18 at 17:25, wrote:
> On 24/05/18 11:23, Jan Beulich wrote:
> On 24.05.18 at 12:13, wrote:
>>> On 24/05/18 09:13, Jan Beulich wrote:
>>> On 24.05.18 at 00:09, wrote:
> It is, as documented, not completely strictly true (according to the
> latest revision of the spec)
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting buffer is similar to the one allocated by the balloon
driver in terms that proper memory reservation is m
From: Oleksandr Andrushchenko
Allow mappings for DMA backed buffers if grant table module
supports such: this extends grant device to not only map buffers
made of balloon pages, but also from buffers allocated with
dma_alloc_xxx.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev.c
From: Oleksandr Andrushchenko
1. Import a dma-buf with the file descriptor provided and export
granted references to the pages of that dma-buf into the array
of grant references.
2. Add API to close all references to an imported buffer, so it can be
released by the owner. This is only v
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf implementation. With this extension grant
references to the pages of an imported dma-buf can be exported
for other dom
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/grant-table.c | 54 +--
include/xen/grant_table
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
co
From: Oleksandr Andrushchenko
Memory {increase|decrease}_reservation and VA mappings update/reset
code used in balloon driver can be made common, so other drivers can
also re-use the same functionality without open-coding.
Create a dedicated module for the shared code and export corresponding
sym
From: Oleksandr Andrushchenko
Allow creating grant device context for use by kernel modules which
require functionality, provided by gntdev. Export symbols for dma-buf
API provided by the module.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev.c| 116 +
From: Oleksandr Andrushchenko
This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends. There is also an existing hyper_dmabuf approach
available [3] which, if reworked to utilize the proposed soluti
On 05/25/2018 06:19 PM, Boris Ostrovsky wrote:
> On 05/25/2018 08:38 AM, Razvan Cojocaru wrote:
>> This patch mirrors the VMX code that doesn't allow
>> vmx_disable_intercept_for_msr()
>
> vmx_clear_msr_intercept() ?
>
>> to clear interception of MSRs that
>> an introspection agent is trying to
On 24/05/18 11:23, Jan Beulich wrote:
On 24.05.18 at 12:13, wrote:
>> On 24/05/18 09:13, Jan Beulich wrote:
>> On 24.05.18 at 00:09, wrote:
It is, as documented, not completely strictly true (according to the
latest revision of the spec), but is there deliberately to simply so
On Tue, Mar 27, Roger Pau Monne wrote:
> Allow the path to be set from a configure command line option.
Please backport 641f9ce2fa to 4.10 ASAP. See
https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg02749.html
Thanks.
Olaf
signature.asc
Description: PGP signature
___
>>> On 25.05.18 at 15:52, wrote:
> On 25/05/18 08:17, Jan Beulich wrote:
> On 24.05.18 at 18:44, wrote:
>>> On 22/05/18 11:33, Jan Beulich wrote:
Other than in the feature sets, where we indeed want to offer the
feature even if not enumerated on hardware, we shouldn't dictate the
>>
Julien Grall writes ("Re: [Xen-devel] [OSSTEST PATCH] ap-common: Switch to
Linux 4.14 by default on X86."):
> Would it be possible to update your CC with my Arm e-mail from now on?
Sorry, I copied it from an old commit.
> FWIW, linux-arm-xen branch is using 4.14.9. I had to upgrade it in order
Hi Ian,
Would it be possible to update your CC with my Arm e-mail from now on?
On 25/05/18 15:44, Ian Jackson wrote:
Linux 4.9 is getting a bit long in the tooth. 4.14 is an LTS branch
and the osstest-tested version seems reasonably good. I ran a special
report[1] to see what to expect and it
This run is configured for baseline tests only.
flight 74742 xen-4.10-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74742/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win10-i386 10 wind
On Fri, May 25, 2018 at 03:44:53PM +0100, Ian Jackson wrote:
> Linux 4.9 is getting a bit long in the tooth. 4.14 is an LTS branch
> and the osstest-tested version seems reasonably good. I ran a special
> report[1] to see what to expect and it reported no regressions.
>
> Accordingly I am going
Linux 4.9 is getting a bit long in the tooth. 4.14 is an LTS branch
and the osstest-tested version seems reasonably good. I ran a special
report[1] to see what to expect and it reported no regressions.
Accordingly I am going to switch to using Linux 4.14 by default for
most X86 runs in osstest.
Am Tue, 22 May 2018 12:14:29 +0100
schrieb Wei Liu :
> I think your predicate is correct. Sorry for the noise.
Is there anything else to be done to get this fixed?
Olaf
pgpyQZGDs0CyK.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailin
On 25/05/18 08:17, Jan Beulich wrote:
On 24.05.18 at 18:44, wrote:
>> On 22/05/18 11:33, Jan Beulich wrote:
>>> Other than in the feature sets, where we indeed want to offer the
>>> feature even if not enumerated on hardware, we shouldn't dictate the
>>> feature being available if tool stack
>>> On 25.05.18 at 14:03, wrote:
> On Fri, May 25, 2018 at 05:50:12AM -0600, Jan Beulich wrote:
>> >>> On 24.05.18 at 18:05, wrote:
>> > This is a step towards consolidating relevant data structures and
>> > defines to one location.
>>
>> Sort of contrary to what the patch does - it converts one
On 25/05/18 14:05, Jan Beulich wrote:
On 25.05.18 at 14:03, wrote:
>> On Fri, May 25, 2018 at 05:50:12AM -0600, Jan Beulich wrote:
>> On 24.05.18 at 18:05, wrote:
This is a step towards consolidating relevant data structures and
defines to one location.
>>> Sort of contrary to
flight 123122 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123122/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 16 guest-localmigrate/x10
fail in 122960 pass in 123122
te
On 25/05/18 12:08, Jan Beulich wrote:
> Even with opt_msr_sc_{pv,hvm} both false we should set up the variable
> as usual, to ensure proper one-time setup during boot and CPU bringup.
> This then also brings the code in line with the comment immediately
> ahead of the printk() being modified saying
This patch mirrors the VMX code that doesn't allow
vmx_disable_intercept_for_msr() to clear interception of MSRs that
an introspection agent is trying to monitor.
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/hvm/svm/svm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
On Fri, May 25, 2018 at 05:50:12AM -0600, Jan Beulich wrote:
> >>> On 24.05.18 at 18:05, wrote:
> > This is a step towards consolidating relevant data structures and
> > defines to one location.
>
> Sort of contrary to what the patch does - it converts one instance of the
> structure to two of th
On Thu, May 24, 2018 at 05:29:43PM +0200, Michal Hocko wrote:
> > ie if we had more,
> > could we solve our pain by making them more generic?
>
> Well, if you have more you will consume more bits in the struct pages,
> right?
Not necessarily ... the zone number is stored in the struct page
curren
>>> On 24.05.18 at 18:05, wrote:
> This is a step towards consolidating relevant data structures and
> defines to one location.
Sort of contrary to what the patch does - it converts one instance of the
structure to two of them.
Jan
___
Xen-devel mai
On 25/05/18 12:36, Jan Beulich wrote:
On 25.05.18 at 10:36, wrote:
>> On 25/05/2018 08:49, Jan Beulich wrote:
>> On 22.05.18 at 13:20, wrote:
@@ -1650,22 +1641,81 @@ static void vmx_update_guest_cr(struct vcpu *v,
>> unsigned int cr,
static void vmx_update_guest_efer(s
>>> On 25.05.18 at 13:31, wrote:
> On 25/05/18 12:17, Jan Beulich wrote:
> On 25.05.18 at 12:52, wrote:
>>> --- a/xen/arch/x86/smpboot.c
>>> +++ b/xen/arch/x86/smpboot.c
>>> @@ -794,7 +794,7 @@ static int setup_cpu_root_pgt(unsigned int cpu)
>>> /* SH_LINEAR_PT inserted together with gue
>>> On 25.05.18 at 10:36, wrote:
> On 25/05/2018 08:49, Jan Beulich wrote:
> On 22.05.18 at 13:20, wrote:
>>> @@ -1650,22 +1641,81 @@ static void vmx_update_guest_cr(struct vcpu *v,
> unsigned int cr,
>>>
>>> static void vmx_update_guest_efer(struct vcpu *v)
>>> {
>>> -unsigned long
On 25/05/18 12:17, Jan Beulich wrote:
On 25.05.18 at 12:52, wrote:
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -794,7 +794,7 @@ static int setup_cpu_root_pgt(unsigned int cpu)
>> /* SH_LINEAR_PT inserted together with guest mappings. */
>> /* PERDOMAIN inse
>>> On 25.05.18 at 12:52, wrote:
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -794,7 +794,7 @@ static int setup_cpu_root_pgt(unsigned int cpu)
> /* SH_LINEAR_PT inserted together with guest mappings. */
> /* PERDOMAIN inserted during context switch. */
>
> -/*
Even with opt_msr_sc_{pv,hvm} both false we should set up the variable
as usual, to ensure proper one-time setup during boot and CPU bringup.
This then also brings the code in line with the comment immediately
ahead of the printk() being modified saying "irrespective of guests".
Signed-off-by: Jan
The comments became stale when c/s d1d6fc97d66 "x86/xpti: really hide almost
all of Xen image" altered how the stubs were mapped.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Juergen Gross
---
xen/arch/x86/smpboot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On 25/05/18 07:02, Jan Beulich wrote:
> We should index an L1 table with an L1 index.
>
> Reported-by: Simon Gaiser
> Signed-off-by: Jan Beulich
Indeed we should.
Reviewed-by: Andrew Cooper , and I've got a
followup patch to fix some stale comments.
> ---
> v2: Entirely different.
>
> --- a/xe
On Fri, May 25, 2018 at 11:01:18AM +0100, Andrew Cooper wrote:
> On 25/05/18 10:49, Wei Liu wrote:
> > On Fri, May 25, 2018 at 11:41:04AM +0200, Roger Pau Monné wrote:
> >> On Thu, May 24, 2018 at 05:05:19PM +0100, Wei Liu wrote:
> >>> They are moved to a new header which is going to be consumed by
Andrew Cooper writes ("Re: [PATCH] libxc/x86/PV: don't hand through CPUID leaf
0x8008 as is"):
> On 22/05/18 12:41, Wei Liu wrote:
> > On Tue, May 22, 2018 at 05:40:02AM -0600, Jan Beulich wrote:
> >> Just like for HVM the feature set should be used for EBX output, while
> >> EAX should be res
On 22/05/18 12:41, Wei Liu wrote:
> On Tue, May 22, 2018 at 05:40:02AM -0600, Jan Beulich wrote:
>> Just like for HVM the feature set should be used for EBX output, while
>> EAX should be restricted to the low 16 bits and ECX/EDX should be zero.
>>
>> Signed-off-by: Jan Beulich
> I will leave this
On 25/05/18 10:49, Wei Liu wrote:
> On Fri, May 25, 2018 at 11:41:04AM +0200, Roger Pau Monné wrote:
>> On Thu, May 24, 2018 at 05:05:19PM +0100, Wei Liu wrote:
>>> They are moved to a new header which is going to be consumed by both
>>> the hypervisor and toolstack.
>>>
>>> Create a new directory
On Fri, May 25, 2018 at 11:41:04AM +0200, Roger Pau Monné wrote:
> On Thu, May 24, 2018 at 05:05:19PM +0100, Wei Liu wrote:
> > They are moved to a new header which is going to be consumed by both
> > the hypervisor and toolstack.
> >
> > Create a new directory for this kind of headers in anticipa
From: Michal Hocko [mailto:mho...@kernel.org]
Sent: Thursday, May 24, 2018 8:19 PM>
> > Let me try to reply your questions.
> > Exactly, GFP_ZONE_TABLE is too complicated. I think there are two advantages
> > from the series of patches.
> >
> > 1. XOR operation is simple and efficient, GFP_ZONE_TA
On Thu, May 24, 2018 at 05:05:19PM +0100, Wei Liu wrote:
> They are moved to a new header which is going to be consumed by both
> the hypervisor and toolstack.
>
> Create a new directory for this kind of headers in anticipation of
^
On Fri, May 25, 2018 at 11:31:17AM +0200, Roger Pau Monné wrote:
> On Thu, May 24, 2018 at 05:05:18PM +0100, Wei Liu wrote:
> > This is a step towards consolidating relevant data structures and
> > defines to one location.
> >
> > It then requires defining cpuid_leaf in user space harness headers
On Thu, May 24, 2018 at 05:05:18PM +0100, Wei Liu wrote:
> This is a step towards consolidating relevant data structures and
> defines to one location.
>
> It then requires defining cpuid_leaf in user space harness headers to
> make them continue to compile.
>
> No functional change.
>
> Signed-
On Thu 2018-05-24 09:35:42, Thomas Garnier wrote:
> On Thu, May 24, 2018 at 4:03 AM Pavel Machek wrote:
>
> > On Wed 2018-05-23 12:54:03, Thomas Garnier wrote:
> > > Change the assembly code to use only relative references of symbols for
> the
> > > kernel to be PIE compatible.
> > >
> > > Positi
On Thu 2018-05-24 09:37:20, Thomas Garnier wrote:
> On Thu, May 24, 2018 at 4:04 AM Pavel Machek wrote:
>
> > On Wed 2018-05-23 12:54:05, Thomas Garnier wrote:
> > > Change the assembly code to use only relative references of symbols for
> the
> > > kernel to be PIE compatible.
> > >
> > > Positi
Hi,
On 25/05/18 05:41, Manish Jaggi wrote:
On 05/25/2018 01:59 AM, Sameer Goel wrote:
On 05/23/2018 10:48 PM, Manish Jaggi wrote:
Hi Sameer,
General Comment, please use appropriate variable names for XXX_domain
structures in code which is xen specific.
I thought that we had discussed th
On 25/05/2018 08:49, Jan Beulich wrote:
On 22.05.18 at 13:20, wrote:
>> @@ -1650,22 +1641,81 @@ static void vmx_update_guest_cr(struct vcpu *v,
>> unsigned int cr,
>>
>> static void vmx_update_guest_efer(struct vcpu *v)
>> {
>> -unsigned long vm_entry_value;
>> +unsigned long ent
>>> On 25.05.18 at 02:52, wrote:
> I'm trying to apply xsa263 patches, specifically for 4.10. However they
> dont seem to on top of 4.10.1 release.
>
> I see they do apply cleanly to current 4.10 staging branch. Are staging
> trees for stable branches like 4.10 considered suitable/safe to rebas
>>> On 22.05.18 at 13:20, wrote:
> @@ -1650,22 +1641,81 @@ static void vmx_update_guest_cr(struct vcpu *v,
> unsigned int cr,
>
> static void vmx_update_guest_efer(struct vcpu *v)
> {
> -unsigned long vm_entry_value;
> +unsigned long entry_ctls, guest_efer = v->arch.hvm_vcpu.guest_efe
On 25/05/2018 08:27, Jan Beulich wrote:
On 24.05.18 at 18:48, wrote:
>> On 24/05/18 17:01, Roger Pau Monné wrote:
>>> On Tue, May 22, 2018 at 12:20:46PM +0100, Andrew Cooper wrote:
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -306,6 +306,
flight 123091 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123091/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 122991 pass
in 123091
test-armhf-armhf-xl-
>>> On 24.05.18 at 22:26, wrote:
> On 05/24/2018 01:57 AM, Jan Beulich wrote:
> On 24.05.18 at 02:46, wrote:
>>> --- /dev/null
>>> +++ b/xen/include/xen/linux_compat.h
>> I continue to dislike the idea of having a header with these contents in
> this location.
> As explained previously this
flight 123120 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/123120/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 123010
test-armhf-armhf-libvirt 14 saveresto
>>> On 24.05.18 at 18:48, wrote:
> On 24/05/18 17:01, Roger Pau Monné wrote:
>> On Tue, May 22, 2018 at 12:20:46PM +0100, Andrew Cooper wrote:
>>> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
>>> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
>>> @@ -306,6 +306,8 @@ extern u64 vmx_ept_vpid_cap;
>>> (vm
>>> On 24.05.18 at 18:44, wrote:
> On 22/05/18 11:33, Jan Beulich wrote:
>> Other than in the feature sets, where we indeed want to offer the
>> feature even if not enumerated on hardware, we shouldn't dictate the
>> feature being available if tool stack or host admin have decided not
>> to expose
>>> On 24.05.18 at 22:23, wrote:
>
> On 05/24/2018 01:53 AM, Jan Beulich wrote:
> On 24.05.18 at 02:46, wrote:
>>> Port WARN_ON_ONCE macro from Linux.
>> In such a case you should justify adjustments you've made:
> I can add more details, but have mostly just changed variable names. The
>
84 matches
Mail list logo
