>>> On 18.12.16 at 11:47, wrote:
> On 18/12/2016 10:38, Andrew Cooper wrote:
>> On 18/12/2016 05:21, osstest service owner wrote:
>>> flight 103540 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/103540/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and
>>> On 16.12.16 at 23:56, wrote:
> From: "Yann E. MORIN"
>
> When CFLAGS are passed from the environment,
But that's what shouldn't be done.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 103744 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103744/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 103742
versi
When putting together commit 3b61726458 ("x86: introduce and use
scratch CPU mask") I failed to remember that AMD IOMMU setups needs the
scratch mask prior to smp_prepare_cpus() having run. Use a static mask
for the boot CPU instead.
Note that the definition of scratch_cpu0mask could also be put i
Also replace implicit 0 checks with X86EMUL_OKAY
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/x86_emulate/x86_emulate.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
b/xen/arch/x86/x86_emulate/x86_emulate.c
i
Hi,
On 16/12/2016 15:49, Julien Grall wrote:
On 14/12/16 08:00, Jiandi An wrote:
Xen currently doesn't map ECAM space specified in static ACPI table.
Seeking opinion on how this should be handled properly.
Each root complex ECAM region takes up 64K 4K pages (256MB).
For some platforms there mig
On 19/12/16 09:45, Jan Beulich wrote:
> When putting together commit 3b61726458 ("x86: introduce and use
> scratch CPU mask") I failed to remember that AMD IOMMU setups needs the
> scratch mask prior to smp_prepare_cpus() having run. Use a static mask
> for the boot CPU instead.
>
> Note that the d
On Wed, 2016-12-14 at 16:08 -0500, Daniel De Graaf wrote:
> On 12/09/2016 11:17 AM, Cédric Bosdonnat wrote:
> > vtpm.txt is referenced in xl.cfg man page. Convert it to pod,
> > move it to the man folder and update the reference.
> >
> > Signed-off-by: Cédric Bosdonnat
>
> Since this manpage onl
Commit-ID: 1c52d859cb2d417e7216d3e56bb7fea88444cec9
Gitweb: http://git.kernel.org/tip/1c52d859cb2d417e7216d3e56bb7fea88444cec9
Author: Andy Lutomirski
AuthorDate: Fri, 9 Dec 2016 10:24:05 -0800
Committer: Thomas Gleixner
CommitDate: Mon, 19 Dec 2016 11:54:20 +0100
x86/asm/32: Make sync
Commit-ID: 426d1aff3138cf38da14e912df3c75e312f96e9e
Gitweb: http://git.kernel.org/tip/426d1aff3138cf38da14e912df3c75e312f96e9e
Author: Andy Lutomirski
AuthorDate: Fri, 9 Dec 2016 10:24:06 -0800
Committer: Thomas Gleixner
CommitDate: Mon, 19 Dec 2016 11:54:20 +0100
Revert "x86/boot: Fai
Commit-ID: c198b121b1a1d7a7171770c634cd49191bac4477
Gitweb: http://git.kernel.org/tip/c198b121b1a1d7a7171770c634cd49191bac4477
Author: Andy Lutomirski
AuthorDate: Fri, 9 Dec 2016 10:24:08 -0800
Committer: Thomas Gleixner
CommitDate: Mon, 19 Dec 2016 11:54:21 +0100
x86/asm: Rewrite sync
Commit-ID: 484d0e5c7943644cc46e7308a8f9d83be598f2b9
Gitweb: http://git.kernel.org/tip/484d0e5c7943644cc46e7308a8f9d83be598f2b9
Author: Andy Lutomirski
AuthorDate: Fri, 9 Dec 2016 10:24:07 -0800
Committer: Thomas Gleixner
CommitDate: Mon, 19 Dec 2016 11:54:21 +0100
x86/microcode/intel:
>>> On 19.12.16 at 11:22, wrote:
> Also replace implicit 0 checks with X86EMUL_OKAY
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
flight 103741 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103741/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-36 xen-boot fail REGR. vs. 103466
test-amd64-amd64-q
flight 103745 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103745/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 103742
versi
On 19/12/16 03:56, Jiandi An wrote:
> Ensure all reserved fields of xatp are zero before making hypervisor
> call to XEN in xen_map_device_mmio(). xenmem_add_to_physmap_one() in
> XEN fails the mapping request if extra.res reserved field in xatp is
> not zero for XENMAPSPACE_dev_mmio request.
>
>
Hi Edgar,
On 16/12/2016 18:04, Edgar E. Iglesias wrote:
On Fri, Dec 16, 2016 at 04:12:00PM +, Julien Grall wrote:
On 15/12/16 11:26, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Relax the mapping of mmio-sram nodes that do not set the
no-memory-wc property to cached normal memory.
On Fri, Dec 16, 2016 at 05:03:13PM +, Julien Grall wrote:
> (CC rest maintainers for event channel questions)
>
> On 16/12/16 10:06, Bhupinder Thakur wrote:
> >Hi,
>
> Hi Bhupinder,
>
> >The idea is for Xen to act as an intermediary as shown below:
> >
> > ring buffers
> >
Hi,
>On 16/12/2016 15:49, Julien Grall wrote:
>> On 14/12/16 08:00, Jiandi An wrote:
>>> Xen currently doesn't map ECAM space specified in static ACPI table.
>>> Seeking opinion on how this should be handled properly.
>>> Each root complex ECAM region takes up 64K 4K pages (256MB).
>>> For some pl
flight 103746 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103746/
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
On 19/12/2016 13:20, Jaggi, Manish wrote:
On 16/12/2016 15:49, Julien Grall wrote:
On 14/12/16 08:00, Jiandi An wrote:
Xen currently doesn't map ECAM space specified in static ACPI table.
Seeking opinion on how this should be handled properly.
Each root complex ECAM region takes up 64K 4K pag
On 12/18/2016 03:44 AM, Ingo Molnar wrote:
> * Boris Ostrovsky wrote:
>
>> On 12/08/2016 11:33 PM, Ingo Molnar wrote:
>>> * Boris Ostrovsky wrote:
>>>
The new Xen PVH entry point requires page tables to be setup by the
kernel since it is entered with paging disabled.
Pull the
>>> On 17.12.16 at 00:18, wrote:
> These registers (pm1a specifically) are not all specific to pm timer
> and are accessed by non-pmtimer code (for example, sleep/power button
> emulation).
>
> The public name for save state structure is kept as 'pmtimer' to avoid
> code churn with the expected c
>>> On 17.12.16 at 00:18, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1425,6 +1425,15 @@ long arch_do_domctl(
> }
> break;
>
> +case XEN_DOMCTL_acpi_access:
> +if ( !is_hvm_domain(d) )
> +ret = -EINVAL;
I think it would be b
flight 103740 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103740/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 101737
test-amd64-i386-xl-qe
On 18/12/2016 21:20, "Haozhong Zhang" wrote:
>On 12/16/16 19:03 +, Andrew Cooper wrote:
>>On 16/12/16 13:43, Haozhong Zhang wrote:
>>> diff --git a/include/arch/x86/hvm/vmx/vmcs.h
>>>b/include/arch/x86/hvm/vmx/vmcs.h
>>> new file mode 100644
>>> index 000..e1a6ef8
>>> --- /dev/null
>>>
flight 68243 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68243/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken REGR.
On 12/19/2016 09:17 AM, Jan Beulich wrote:
On 17.12.16 at 00:18, wrote:
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -1425,6 +1425,15 @@ long arch_do_domctl(
>> }
>> break;
>>
>> +case XEN_DOMCTL_acpi_access:
>> +if ( !is_hvm_domain(d) )
flight 103748 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103748/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 15dae68589243726f0374e535a77e76444096bad
baseline version:
ovmf a35dc6499beb0b76c3403
>>> On 19.12.16 at 15:48, wrote:
> On 12/19/2016 09:17 AM, Jan Beulich wrote:
> On 17.12.16 at 00:18, wrote:
>>> --- a/xen/arch/x86/domctl.c
>>> +++ b/xen/arch/x86/domctl.c
>>> @@ -1425,6 +1425,15 @@ long arch_do_domctl(
>>> }
>>> break;
>>>
>>> +case XEN_DOMCTL_acpi_a
Those are used in order to decide which scripts are executed at init.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/hotplug/FreeBSD/rc.d/xencommons.in | 5 -
tools/hotplug/FreeBSD/rc.d/xendriverdomain.in | 5 -
2 files changed, 8 insertions(+), 2 deletio
FreeBSD init scripts don't have /usr/local/{bin/sbin} in it's PATH, which
prevents `xl devd` from working properly since hotplug scripts require the set
of xenstore cli tools to be in PATH.
While there also fix the usage of --pidfile, which according to the xl help
doesn't use "=", and add braces
A couple of minor fixes for FreeBSD init scripts that I've discovered while
playing with FreeBSD driver domains.
Thanks, Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
At the moment the execution of xencommons is gated on the presence of the
privcmd device, but that's not correct, since privcmd is available to all Xen
domains (privileged or unprivileged). Instead of using privcmd use the
xenstored device, which will only be available to the domain that's in charg
...because it's empty. While there also rename xendriverdomain_startcmd to
xendriverdomain_start in order to match the nomenclature of the file.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/hotplug/FreeBSD/rc.d/xendriverdomain.in | 8 +---
1 file changed, 1 inse
flight 103743 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103743/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 3 host-install(3)broken REGR. vs. 101675
test-amd64-i386-libv
On Fri, Dec 16, 2016 at 07:03:49PM +, Andrew Cooper wrote:
> On 16/12/16 13:43, Haozhong Zhang wrote:
> > diff --git a/include/arch/x86/hvm/vmx/vmcs.h
> > b/include/arch/x86/hvm/vmx/vmcs.h
> > new file mode 100644
> > index 000..e1a6ef8
> > --- /dev/null
> > +++ b/include/arch/x86/hvm/vmx/
On 19/12/16 15:20, Roger Pau Monné wrote:
> On Fri, Dec 16, 2016 at 07:03:49PM +, Andrew Cooper wrote:
>> On 16/12/16 13:43, Haozhong Zhang wrote:
>>> diff --git a/include/arch/x86/hvm/vmx/vmcs.h
>>> b/include/arch/x86/hvm/vmx/vmcs.h
>>> new file mode 100644
>>> index 000..e1a6ef8
>>> ---
On 19/12/16 02:20, Haozhong Zhang wrote:
> On 12/16/16 16:17 +, Andrew Cooper wrote:
>> If so, I don't expect Xen's behaviour to ever change. We'd prefer to do
>> all configuration like that at the toolstack/hypervisor level, rather
>> than the in-guest firmware (if any).
>>
>
> OK, then TODO
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory XSA-204
x86: Mishandling of SYSCALL singlestep during emulation
ISSUE DESCRIPTION
=
The typical behaviour of singlestepping exceptions is determined at the
start of the instruction, w
On 19/12/16 02:44, Haozhong Zhang wrote:
>>> +passed = false;
>>> +}
>>> +
>>> +vmcs_size = (vmx_basic & VMX_BASIC_VMCS_SIZE_MASK) >> 32;
>>> +if ( vmcs_size > PAGE_SIZE )
>>> +{
>>> +xtf_failure("Fail: "
>>> +"VMCS size (%"PRIu64") in MSR_IA32_VM
Lars Kurth writes ("Re: [licensing] was: [XTF PATCH 04/16] vvmx: add C wrappers
of vmxon/vmread/vmptrld"):
> @Andy: you may want to have a chat with Ian and check whether the MPL 2.0
> may be a better choice for XTF than BSD in this case. I have not looked
> into how copyleft and MPL 2 work togeth
On 19/12/16 03:20, Haozhong Zhang wrote:
> On 12/16/16 19:03 +, Andrew Cooper wrote:
>> On 16/12/16 13:43, Haozhong Zhang wrote:
>>> diff --git a/include/arch/x86/hvm/vmx/vmcs.h
>>> b/include/arch/x86/hvm/vmx/vmcs.h
>>> new file mode 100644
>>> index 000..e1a6ef8
>>> --- /dev/null
>>> +++ b
On 19/12/16 03:35, Haozhong Zhang wrote:
> On 12/16/16 20:33 +, Andrew Cooper wrote:
>> On 16/12/16 13:43, Haozhong Zhang wrote:
>>> diff --git a/tests/vvmx/vmxon.c b/tests/vvmx/vmxon.c
>>> index 31f074c..ca33b3c 100644
>>> --- a/tests/vvmx/vmxon.c
>>> +++ b/tests/vvmx/vmxon.c
>>> @@ -28,11 +28
On 12/14/16 3:09 PM, Daniel De Graaf wrote:
> On 12/12/2016 09:00 AM, Anshul Makkar wrote:
>> During guest migrate allow permission to prevent
>> spurious page faults.
>> Prevents these errors:
>> d73: Non-privileged (73) attempt to map I/O space
>>
>> avc: denied { set_misc_info } for do
On 19/12/16 03:35, Haozhong Zhang wrote:
>
>>> +{
>>> +clear_vmcs(vmxon_region, get_vmcs_revid());
>>> +
>>> +unsigned long ret = exec_user(vmxon_in_user);
>>> +uint8_t err = (ret >> 32) & 0xff;
>>> +exinfo_t fault = ret & 0x;
>>> +
>>> +return handle_vmxinsn_err(__func_
On 19/12/16 03:46, Haozhong Zhang wrote:
>> However, I am not sure of its purpose. Why cant you reuse the previous
>> host state area?
>>
>
> Intel SDM says SW should not access or modify the VXMON rgion of a
> logical processor between vmxon and vmxoff. Though I have tested on
> real hardware whe
On 19/12/16 01:44, Haozhong Zhang wrote:
> On 12/16/16 14:12 +, Andrew Cooper wrote:
>> On 16/12/16 13:43, Haozhong Zhang wrote:
>>> This patch series starts to add a test selection "test-hvm64-vvmx" for
>>> nested VMX. This first series focuses mostly on nested vmxon.
>>>
>>> * Patch 01 - 03 t
On 19/12/16 05:31, Haozhong Zhang wrote:
> On 12/16/16 21:26 +, Andrew Cooper wrote:
>> On 16/12/16 13:43, Haozhong Zhang wrote:
>>> This patch series starts to add a test selection "test-hvm64-vvmx" for
>>> nested VMX. This first series focuses mostly on nested vmxon.
>>>
>>> * Patch 01 - 03 t
Introduce vendor_is() to allow emulation to have vendor-specific
behaviour. Adjust the SYSCALL behaviour on Intel to raise #UD when
executed outside of 64bit mode.
in_longmode() has different return semantics from rc, so use a separate
integer for the purpose.
Signed-off-by: Andrew Cooper
---
C
Having the instruction emulator fill in all #UDs when using FEP is unhelpful
when trying to test emulation behaviour against hardware.
Restrict emulation from the #UD intercept to the cross-vendor case, and when a
postive Forced Emulation Prefix has been identified.
Signed-off-by: Andrew Cooper
There is no need for the volatile cast in the timer interrupt. pit0_ticks has
external linkage, preventing the compiler from eliding the update. This
reduces the generated assembly from a read, local modify, write to a single
add instruction.
Drop the memory barriers from timer_irq_works(), as t
Commit 2fdf5b2554 ("x86: streamline copying to/from user memory")
wrongly used "g" here, when it obviously needs to be a register.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/usercopy.c
+++ b/xen/arch/x86/usercopy.c
@@ -141,7 +141,7 @@ unsigned clear_user(void __use
>>> On 19.12.16 at 17:38, wrote:
> There is no need for the volatile cast in the timer interrupt. pit0_ticks has
> external linkage, preventing the compiler from eliding the update. This
> reduces the generated assembly from a read, local modify, write to a single
> add instruction.
I don't thi
On 19/12/16 16:44, Jan Beulich wrote:
> Commit 2fdf5b2554 ("x86: streamline copying to/from user memory")
> wrongly used "g" here, when it obviously needs to be a register.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
__
Use memcpy() rather than individual writes with explicit casts. The
__builtin_memcpy() wrapper does a better job at combining adjacent writes into
a larger word size.
This results in better generated assembly. No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Naka
On 19/12/16 16:51, Jan Beulich wrote:
On 19.12.16 at 17:38, wrote:
>> There is no need for the volatile cast in the timer interrupt. pit0_ticks
>> has
>> external linkage, preventing the compiler from eliding the update. This
>> reduces the generated assembly from a read, local modify, wri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-10013 / XSA-204
version 2
x86: Mishandling of SYSCALL singlestep during emulation
UPDATES IN VERSION 2
CVE assigned.
ISSUE DESCRIPTION
===
This run is configured for baseline tests only.
flight 68244 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68244/
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-insta
Hi Stefano,
On 17/12/2016 02:13, Stefano Stabellini wrote:
On Fri, 16 Dec 2016, Stefano Stabellini wrote:
On Fri, 16 Dec 2016, Julien Grall wrote:
Hi Stefano,
On 16/12/16 00:08, Stefano Stabellini wrote:
On Thu, 15 Dec 2016, Julien Grall wrote:
On 15/12/2016 01:04, Stefano Stabellini wrote:
On Sat, Dec 17, 2016 at 7:51 AM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Francis wrote:
>> Signed-off-by: Alistair Francis
>
>
> Why?
Hey Konrad,
The problem that I have is that we build Xen releases in buildroot. As
things change (GCC version usually)
On Sat, Dec 17, 2016 at 7:55 AM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Dec 16, 2016 at 02:56:04PM -0800, Alistair Francis wrote:
>> To avoid this build error with newer build systems:
>
> And what is newer? GCC 5? 6?
In this case it is GCC 5.
Thanks,
Alistair
>
> Thanks.
>> error: #warning
On Sat, Dec 17, 2016 at 7:56 AM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Dec 16, 2016 at 02:56:05PM -0800, Alistair Francis wrote:
>> To avoid this build error with newer build systems:
>> error: #warning redirecting incorrect #include to
>> [-Werror=cpp]
>
> And what is the 'newer
flight 103751 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103751/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 3 host-install(3)broken REGR. vs.
On Mon, 19 Dec 2016, Juergen Gross wrote:
> On 19/12/16 03:56, Jiandi An wrote:
> > Ensure all reserved fields of xatp are zero before making hypervisor
> > call to XEN in xen_map_device_mmio(). xenmem_add_to_physmap_one() in
> > XEN fails the mapping request if extra.res reserved field in xatp is
On Wednesday, December 14, 2016 4:22 PM Michal Hocko, wrote:
> Ohh, I can see it now. This is not an upstream commit. This is a 3.18.37
> backport which was wrong! You need the follow up fix 52c84a95dc6a
> ("4.1.28 Fix bad backport of 8f182270dfec "mm/swap.c: flush lru pvecs on
> compound page arr
On 12/19/2016 11:55 AM, Andrew Cooper wrote:
> Use memcpy() rather than individual writes with explicit casts. The
> __builtin_memcpy() wrapper does a better job at combining adjacent writes into
> a larger word size.
>
> This results in better generated assembly. No functional change.
>
> Signed
On Mon, 19 Dec 2016, Christoffer Dall wrote:
> On Fri, Dec 16, 2016 at 05:03:13PM +, Julien Grall wrote:
> > (CC rest maintainers for event channel questions)
> >
> > On 16/12/16 10:06, Bhupinder Thakur wrote:
> > >Hi,
> >
> > Hi Bhupinder,
> >
> > >The idea is for Xen to act as an intermedi
flight 103759 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103759/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 9 debian-hvm-install fail REGR. vs.
103746
Tests
On Mon, 19 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 17/12/2016 02:13, Stefano Stabellini wrote:
> > On Fri, 16 Dec 2016, Stefano Stabellini wrote:
> > > On Fri, 16 Dec 2016, Julien Grall wrote:
> > > > Hi Stefano,
> > > >
> > > > On 16/12/16 00:08, Stefano Stabellini wrote:
> > > > > On
Hi Stefano,
On 19/12/2016 23:30, Stefano Stabellini wrote:
On Mon, 19 Dec 2016, Julien Grall wrote:
2) We run gic_update_one_lr and vgic_store_itargetsr in parallel safely
and locklessly. There might be a way to do it, but it is not easy I
haven't found it yet.
Correct me if I am wrong. There
This is actually not an ARM specific question, so changing the subject
and CC'ing more people.
On Wed, 14 Dec 2016, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 13, 2016 at 07:14:27PM -0600, Jiandi An wrote:
> > Hi Guys,
> >
> > Xen currently does not handle mapping of MMIO regions specified under
On Mon, 19 Dec 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 19/12/2016 23:30, Stefano Stabellini wrote:
> > On Mon, 19 Dec 2016, Julien Grall wrote:
> > > > > 2) We run gic_update_one_lr and vgic_store_itargetsr in parallel
> > > > > safely
> > > > > and locklessly. There might be a way to do it
This is not exactly ARM specific, so expanding the CC list.
On Wed, 14 Dec 2016, Jiandi An wrote:
> Hi Guys,
>
> Xen currently does not handle mapping mmio regions specified in standard
> static ACPI tables such as BERT, TPM2, GT block, IORT, HEST, etc. There has
> been some initial discussion
On Mon, 19 Dec 2016, Julien Grall wrote:
> Hi,
>
> On 16/12/2016 15:49, Julien Grall wrote:
> > On 14/12/16 08:00, Jiandi An wrote:
> > > Xen currently doesn't map ECAM space specified in static ACPI table.
> > > Seeking opinion on how this should be handled properly.
> > > Each root complex ECAM
On Mon, 19 Dec 2016, Julien Grall wrote:
> Hi Edgar,
>
> On 16/12/2016 18:04, Edgar E. Iglesias wrote:
> > On Fri, Dec 16, 2016 at 04:12:00PM +, Julien Grall wrote:
> > > On 15/12/16 11:26, Edgar E. Iglesias wrote:
> > > > From: "Edgar E. Iglesias"
> > > >
> > > > Relax the mapping of mmio-s
flight 103760 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103760/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 17 guest-start/debianhvm.repeat fail
REGR. vs. 103
Hi all,
as you know, we have an issue with the speed of review and acceptance of
new PV drivers. In a discussion among committers, George wrote an email
with a short proposal to clarify the development lifecycle of new PV
drivers and the different expectations at each stage of the process. I
took
flight 103747 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103747/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs.
103466
test-amd64
flight 103749 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103749/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 101737
test-amd64-i386-xl-qe
On 12/19/16 16:34 +, Andrew Cooper wrote:
On 19/12/16 05:31, Haozhong Zhang wrote:
On 12/16/16 21:26 +, Andrew Cooper wrote:
On 16/12/16 13:43, Haozhong Zhang wrote:
This patch series starts to add a test selection "test-hvm64-vvmx" for
nested VMX. This first series focuses mostly on n
On 12/19/16 15:41 +, Andrew Cooper wrote:
On 19/12/16 02:44, Haozhong Zhang wrote:
+passed = false;
+}
+
+vmcs_size = (vmx_basic & VMX_BASIC_VMCS_SIZE_MASK) >> 32;
+if ( vmcs_size > PAGE_SIZE )
+{
+xtf_failure("Fail: "
+"VMCS size (%"PRIu64
On 12/19/16 16:07 +, Andrew Cooper wrote:
On 19/12/16 03:46, Haozhong Zhang wrote:
However, I am not sure of its purpose. Why cant you reuse the previous
host state area?
Intel SDM says SW should not access or modify the VXMON rgion of a
logical processor between vmxon and vmxoff. Though
flight 103753 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103753/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-23 host-install(3)broken REGR. vs. 103407
test-amd64-amd6
On 12/17/16 9:51 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Dec 16, 2016 at 02:56:01PM -0800, Alistair Francis wrote:
>> Signed-off-by: Alistair Francis
>
>
> Why?
*adjusts his distro maintainer hat* It's considered really bad form for
upstreams to push -Werror in their projects. However I know
flight 103761 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103761/
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
On 12/19/16 12:01 PM, Alistair Francis wrote:
> On Sat, Dec 17, 2016 at 7:55 AM, Konrad Rzeszutek Wilk
> wrote:
>> On Fri, Dec 16, 2016 at 02:56:04PM -0800, Alistair Francis wrote:
>>> To avoid this build error with newer build systems:
>>
>> And what is newer? GCC 5? 6?
>
> In this case it is GC
On 12/19/16 12:02 PM, Alistair Francis wrote:
> On Sat, Dec 17, 2016 at 7:56 AM, Konrad Rzeszutek Wilk
> wrote:
>> On Fri, Dec 16, 2016 at 02:56:05PM -0800, Alistair Francis wrote:
>>> To avoid this build error with newer build systems:
>>> error: #warning redirecting incorrect #include to
>>
On 12/19/16 10:02 AM, Doug Goldstein wrote:
> On 12/14/16 3:09 PM, Daniel De Graaf wrote:
>> On 12/12/2016 09:00 AM, Anshul Makkar wrote:
>>> During guest migrate allow permission to prevent
>>> spurious page faults.
>>> Prevents these errors:
>>> d73: Non-privileged (73) attempt to map I/O space 0
flight 103752 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103752/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 103160
test-amd64-i386
On 12/19/16 12:49, Stefano Stabellini wrote:
> On Mon, 19 Dec 2016, Juergen Gross wrote:
>> On 19/12/16 03:56, Jiandi An wrote:
>>> Ensure all reserved fields of xatp are zero before making hypervisor
>>> call to XEN in xen_map_device_mmio(). xenmem_add_to_physmap_one() in
>>> XEN fails the mappin
> From: Zhang, Haozhong
> Sent: Monday, December 19, 2016 9:14 AM
>
> c/s 08fac63 misused v->domain-arch.paging.gfn_bits as the width of
> guest physical address and missed adding PAGE_SHIFT to it when
> checking vmxon operand.
>
> Signed-off-by: Haozhong Zhang
Acked-by: Kevin Tian
__
> From: Zhang, Haozhong
> Sent: Thursday, December 15, 2016 8:46 PM
>
> Replace vmreturn() by vmsucceed(), vmfail(), vmfail_valid() and
> vmfail_invalid(), which are consistent to the pseudo code on Intel
> SDM, and allow to return VM instruction error numbers to L1
> hypervisor.
>
> Signed-off-b
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, December 14, 2016 10:26 PM
>
> paging_mark_gfn_dirty() actually takes a pfn, even by paramter name. Rename
> the function and alter the type to pfn_t to match.
>
> Push pfn_t into the LOGDIRTY_IDX() macros, and clean up
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Tuesday, December 20, 2016 12:55 AM
>
> Use memcpy() rather than individual writes with explicit casts. The
> __builtin_memcpy() wrapper does a better job at combining adjacent writes into
> a larger word size.
>
> This results in
flight 103750 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103750/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm3 host-install(3) broken in 103743 REGR. vs. 101675
test-amd64-i386-libv
> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
> Sent: Friday, December 16, 2016 5:40 PM
>
> From 89fffdd6b563b2723e24d17231715bb8c9f24f90 Mon Sep 17 00:00:00 2001
> From: Quan Xu
> Date: Fri, 16 Dec 2016 17:24:01 +0800
> Subject: [PATCH v3] x86/apicv: fix RTC periodic timer and apicv issue
On December 20, 2016 1:37 PM, Tian, Kevin wrote:
>> From: Xuquan (Quan Xu) [mailto:xuqu...@huawei.com]
>> Sent: Friday, December 16, 2016 5:40 PM
>>
>> From 89fffdd6b563b2723e24d17231715bb8c9f24f90 Mon Sep 17 00:00:00
>2001
>> From: Quan Xu
>> Date: Fri, 16 Dec 2016 17:24:01 +0800
>> Subject: [PAT
flight 103754 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103754/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 3 host-install(3)broken REGR. vs. 103419
test-amd64-amd6
On 12/19/16 07:11, Julien Grall wrote:
>
>
> On 19/12/2016 13:20, Jaggi, Manish wrote:
>>> On 16/12/2016 15:49, Julien Grall wrote:
On 14/12/16 08:00, Jiandi An wrote:
> Xen currently doesn't map ECAM space specified in static ACPI table.
> Seeking opinion on how this should be handl
1 - 100 of 106 matches
Mail list logo
