>>> On 20.12.16 at 00:39, wrote:
> On Wed, 14 Dec 2016, Jiandi An wrote:
>> 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 discussions on using whitelist and leave it up t
>>> On 20.12.16 at 00:01, wrote:
> 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:
>> > Xen currently does not handle mapping of MMI
>>> On 20.12.16 at 01:47, wrote:
> ## Design Phase
>
> The first step toward acceptance of a new PV protocol is to write a
> design document and send it to xen-devel. It should cover the xenstore
> handshake mechanism, the ABI, how the protocol works and anything else
> which is required to write
>>> On 19.12.16 at 17:55, 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.
I don't think gener
>>> On 19.12.16 at 17:58, wrote:
> 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 generate
flight 103758 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103758/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf ee3e2656886a3bfdee19c73d3ab9e8589c05af12
baseline version:
xtf be285228fca8af149ac92c
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
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 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
> 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
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: 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
> 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: 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: 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
__
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
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 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
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 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
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/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 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/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
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: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
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
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
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 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
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
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
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 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 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
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
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
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, 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
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 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 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
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 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
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: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)
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:
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
-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
===
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
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: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
__
>>> 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
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
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
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
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
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
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 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 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 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:
> 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 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
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 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
-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: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
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 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/
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
...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
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
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
>>> 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
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 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 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 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 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 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
>>> 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 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 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
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
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
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 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 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.
>
>
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
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
>>> 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
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:
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: 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: 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
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
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
1 - 100 of 106 matches
Mail list logo
