On Thu, Nov 21, 2019 at 9:38 AM Andrew Cooper wrote:
>
> On 21/11/2019 17:31, Roman Shaposhnik wrote:
> > On Wed, Nov 20, 2019 at 10:06 PM Jürgen Groß wrote:
> >> Where do we stand with Xen 4.13 regarding blockers and related patches?
> >>
> >> 1. OSStest failure regarding nested test:
> >>
On 22.11.19 19:52, George Dunlap wrote:
"Linear pagetables" is a technique which involves either pointing a
pagetable at itself, or to another pagetable the same or higher level.
Xen has limited support for linear pagetables: A page may either point
to itself, or point to another page of the
On 22.11.19 18:54, Andrew Cooper wrote:
It turns out that the XSA-304 / CVE-2018-12207 fix of disabling executable
superpages doesn't work well with the nested p2m code.
Nested virt is experimental and not security supported, but is useful for
development purposes. In order to not regress the
On 11/5/19 11:49 AM, Andrew Cooper wrote:
The safety of livepatching depends on every stack having been unwound, but
there is one corner case where this is not true. The Sharing/Paging/Monitor
infrastructure may use waitqueues, which copy the stack frame sideways and
longjmp() to a different
On 11/13/19 8:46 AM, Jason Gunthorpe wrote:
On Wed, Nov 13, 2019 at 05:59:52AM -0800, Christoph Hellwig wrote:
+int mmu_interval_notifier_insert(struct mmu_interval_notifier *mni,
+ struct mm_struct *mm, unsigned long start,
+
flight 144251 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144251/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
flight 144246 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144246/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144025
Tests
On 22.11.2019 13:58, Andrew Cooper wrote:
On 22/11/2019 12:57, Jan Beulich wrote:
On 22.11.2019 13:50, Andrew Cooper wrote:
On 22/11/2019 12:46, Jan Beulich wrote:
Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
"Some Coffee Lake platforms have a skewed HPET timer once the SoCs
flight 144249 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144249/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Thu, 21 Nov 2019, Pavel Tatashin wrote:
> privcmd_call requires to enable access to userspace for the
> duration of the hypercall.
>
> Currently, this is done via assembly macros. Change it to C
> inlines instead.
>
> Signed-off-by: Pavel Tatashin
I am OK with this.
Acked-by: Stefano
On Fri, 22 Nov 2019, Peng Fan wrote:
> The end should be GICD_ISACTIVERN not GICD_ISACTIVER,
> and also print a warning for the unhandled read.
>
> Signed-off-by: Peng Fan
> ---
>
> V2:
> Add a warning message
>
> xen/arch/arm/vgic-v3.c | 5 -
> 1 file changed, 4 insertions(+), 1
"Linear pagetables" is a technique which involves either pointing a
pagetable at itself, or to another pagetable the same or higher level.
Xen has limited support for linear pagetables: A page may either point
to itself, or point to another page of the same level (i.e., L2 to L2,
L3 to L3, and so
On 22/11/2019 18:08, George Dunlap wrote:
> On Fri, Nov 22, 2019 at 5:55 PM Andrew Cooper
> wrote:
>> It turns out that the XSA-304 / CVE-2018-12207 fix of disabling executable
>> superpages doesn't work well with the nested p2m code.
>>
>> Nested virt is experimental and not security supported,
Wei Liu writes ("Re: [Xen-devel] [PATCH v2 1/3] libxl: introduce new backend
type VINPUT"):
> On Fri, Nov 22, 2019 at 04:43:03PM +0100, Jürgen Groß wrote:
> > Release-acked-by: Juergen Gross
>
> I take it this applies to both patch 1 and 3?
In the absence of a reply to the contrary by 21:00
On Fri, Nov 22, 2019 at 5:55 PM Andrew Cooper wrote:
>
> It turns out that the XSA-304 / CVE-2018-12207 fix of disabling executable
> superpages doesn't work well with the nested p2m code.
>
> Nested virt is experimental and not security supported, but is useful for
> development purposes. In
It turns out that the XSA-304 / CVE-2018-12207 fix of disabling executable
superpages doesn't work well with the nested p2m code.
Nested virt is experimental and not security supported, but is useful for
development purposes. In order to not regress the status quo, disable the
XSA-304 workaround
flight 144243 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144243/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 144236
Currently if a user tries to live-load the same or older ucode revision
than CPU already has, he will get a single message in Xen log like:
(XEN) 128 cores are to update their microcode
No actual ucode loading will happen and this situation can be quite
confusing. Fix this by starting ucode
On Fri, Nov 22, 2019 at 04:43:03PM +0100, Jürgen Groß wrote:
> On 22.11.19 16:18, Anthony PERARD wrote:
> > On Thu, Nov 21, 2019 at 08:12:58PM +0200, Oleksandr Grytsov wrote:
> > > From: Oleksandr Grytsov
> > >
> > > There are two kind of VKBD devices: with QEMU backend and user space PV
> > >
flight 144244 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144244/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
144233
Tests which did
On Thu, Nov 21, 2019 at 08:12:58PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> There are two kind of VKBD devices: with QEMU backend and user space PV
> backend. In current implementation they can't be distinguished as both use
> VKBD backend type. As result, user space PV KBD
On 22/11/2019 14:31, Jan Beulich wrote:
> On 22.11.2019 14:55, Andrew Cooper wrote:
>> On 22/11/2019 13:31, Jan Beulich wrote:
>>> On 21.11.2019 23:15, Andrew Cooper wrote:
+/* Fallthrough */
+case 0x62: /* bound */
>>> Does "bound" really belong on this list? It raising #BR
On 22/11/2019 13:39, Jan Beulich wrote:
> On 22.11.2019 14:12, Andrew Cooper wrote:
>> On 22/11/2019 13:08, Jan Beulich wrote:
>>> On 22.11.2019 13:37, Roger Pau Monné wrote:
On Thu, Nov 21, 2019 at 10:15:50PM +, Andrew Cooper wrote:
> The VT-x task switch handler adds inst_len to
On 22/11/2019 13:59, Roger Pau Monné wrote:
> On Thu, Nov 21, 2019 at 10:15:51PM +, Andrew Cooper wrote:
>> The TASK_SWITCH vmexit has fault semantics, and doesn't provide any NRIPs
>> assistance with instruction length. As a result, any instruction-induced
>> task
>> switch has the outgoing
Wei Liu writes ("Re: [PATCH v2 2/3] libxl: rename VKB backend type "linux" to
"pv""):
> The LINUX type was introduced back in 2018.
Oh. Yes. I used a wrong git-describe rune to try to find out where
it had been introduced. The answer in fact is that it was in
4.12.0-rc1. Thanks for pointing
On 22.11.2019 14:55, Andrew Cooper wrote:
> On 22/11/2019 13:31, Jan Beulich wrote:
>> On 21.11.2019 23:15, Andrew Cooper wrote:
>>> +/* Fallthrough */
>>> +case 0x62: /* bound */
>> Does "bound" really belong on this list? It raising #BR is like
>> insns raising random other
On Thu, Nov 21, 2019 at 10:15:51PM +, Andrew Cooper wrote:
> The TASK_SWITCH vmexit has fault semantics, and doesn't provide any NRIPs
> assistance with instruction length. As a result, any instruction-induced task
> switch has the outgoing task's %eip pointing at the instruction switch
On 22/11/2019 13:31, Jan Beulich wrote:
> On 21.11.2019 23:15, Andrew Cooper wrote:
>> --- a/xen/arch/x86/hvm/svm/emulate.c
>> +++ b/xen/arch/x86/hvm/svm/emulate.c
>> @@ -117,6 +117,61 @@ unsigned int svm_get_insn_len(struct vcpu *v, unsigned
>> int instr_enc)
>> }
>>
>> /*
>> + * TASK_SWITCH
On 02.10.2019 19:16, Hongyan Xia wrote:
> We will soon need to clean up mappings whenever the out most loop is
> ended. Add a new label and turn relevant continue's into goto's.
I think already when this still was RFC I did indicate that I'm not
happy about the introduction of these labels
flight 144241 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144241/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144035
Tests
On 22.11.2019 13:58, Andrew Cooper wrote:
> On 22/11/2019 12:57, Jan Beulich wrote:
>> On 22.11.2019 13:50, Andrew Cooper wrote:
>>> On 22/11/2019 12:46, Jan Beulich wrote:
Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
"Some Coffee Lake platforms have a skewed HPET
On 21.11.2019 23:15, Andrew Cooper wrote:
> --- a/xen/arch/x86/hvm/svm/emulate.c
> +++ b/xen/arch/x86/hvm/svm/emulate.c
> @@ -117,6 +117,61 @@ unsigned int svm_get_insn_len(struct vcpu *v, unsigned
> int instr_enc)
> }
>
> /*
> + * TASK_SWITCH vmexits never provide an instruction length. We
On 22/11/2019 13:08, Jan Beulich wrote:
> On 22.11.2019 13:37, Roger Pau Monné wrote:
>> On Thu, Nov 21, 2019 at 10:15:50PM +, Andrew Cooper wrote:
>>> The VT-x task switch handler adds inst_len to rip before calling
>>> hvm_task_switch(). This causes early faults to be delivered to the
On 21/11/2019 22:15, Andrew Cooper wrote:
> The TASK_SWITCH vmexit has fault semantics, and doesn't provide any NRIPs
> assistance with instruction length. As a result, any instruction-induced task
> switch has the outgoing task's %eip pointing at the instruction switch caused
> the switch,
On 22.11.2019 13:37, Roger Pau Monné wrote:
> On Thu, Nov 21, 2019 at 10:15:50PM +, Andrew Cooper wrote:
>> The VT-x task switch handler adds inst_len to rip before calling
>> hvm_task_switch(). This causes early faults to be delivered to the guest
>> with
>> trap semantics, and break
On 22/11/2019 12:57, Jan Beulich wrote:
> On 22.11.2019 13:50, Andrew Cooper wrote:
>> On 22/11/2019 12:46, Jan Beulich wrote:
>>> Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
>>>
>>> "Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
>>> PC10, which in
On 22.11.2019 13:50, Andrew Cooper wrote:
> On 22/11/2019 12:46, Jan Beulich wrote:
>> Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
>>
>> "Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
>> PC10, which in consequence marks TSC as unstable because HPET is
On 22/11/2019 12:46, Jan Beulich wrote:
> Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
>
> "Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
> PC10, which in consequence marks TSC as unstable because HPET is used as
> watchdog clocksource for TSC."
>
>
On Fri, Nov 22, 2019 at 12:19:41PM +0100, Jan Beulich wrote:
>On 22.11.2019 11:52, Sergey Dyasli wrote:
>> Currently if a user tries to live-load the same ucode revision that CPU
>> already has, he will get a single message in Xen log like:
>>
>> (XEN) 128 cores are to update their microcode
Linux commit fc5db58539b49351e76f19817ed1102bf7c712d0 says
"Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
PC10, which in consequence marks TSC as unstable because HPET is used as
watchdog clocksource for TSC."
Follow this for Xen as well. Looking at its patch
On 22/11/2019 12:37, Roger Pau Monné wrote:
> On Thu, Nov 21, 2019 at 10:15:50PM +, Andrew Cooper wrote:
>> The VT-x task switch handler adds inst_len to rip before calling
>> hvm_task_switch(). This causes early faults to be delivered to the guest
>> with
> By early faults you mean faults
On Thu, Nov 21, 2019 at 10:15:50PM +, Andrew Cooper wrote:
> The VT-x task switch handler adds inst_len to rip before calling
> hvm_task_switch(). This causes early faults to be delivered to the guest with
By early faults you mean faults injected by hvm_task_switch itself for
example?
>
flight 144240 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144240/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144025
Tests
On Thu, Nov 21, 2019 at 08:13:00PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov
>
> Adding/removing device is handled for specific devices only: VBD, VIF,
> QDISK. This commit adds default case to handle adding/removing for all PV
> devices by default, except QDISK device, which
On Fri, Nov 22, 2019 at 11:14:41AM +, Ian Jackson wrote:
> Oleksandr Grytsov writes ("[PATCH v2 2/3] libxl: rename VKB backend type
> "linux" to "pv""):
> > From: Oleksandr Grytsov
> >
> > There are two kind of VKB backends: QEMU and user space PV backend.
> > For PV backend "linux" enum is
On Fri, Nov 22, 2019 at 11:02:30AM +, Durrant, Paul wrote:
> > -Original Message-
> > From: Xen-devel On Behalf Of Wei
> > Liu
> > Sent: 21 November 2019 19:51
> > To: Xen Development List
> > Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> > ; Michael Kelley ; Jan
> > Beulich ; Roger Pau
Oleksandr Grytsov writes ("[PATCH v2 0/3] Remove backend xen store entry on
domain destroy"):
> From: Oleksandr Grytsov
>
> Changes since v1:
>
> * add commit to rename VKB backend type "linux" to "pv";
> * add default case to handle adding/removing PV devices in add_device,
> remove_device
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 21 November 2019 17:38
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Stefano Stabellini
> ; Julien Grall ; Wei Liu
> ; Konrad Wilk ; George Dunlap
> ; Andrew Cooper ;
> Ian Jackson
> Subject:
On 22.11.2019 11:52, Sergey Dyasli wrote:
> Currently if a user tries to live-load the same ucode revision that CPU
> already has, he will get a single message in Xen log like:
>
> (XEN) 128 cores are to update their microcode
>
> No actual ucode loading will happen and this situation can be
Oleksandr Grytsov writes ("[PATCH v2 3/3] libxl: make default path to
add/remove all PV devices"):
> From: Oleksandr Grytsov
>
> Adding/removing device is handled for specific devices only: VBD, VIF,
> QDISK. This commit adds default case to handle adding/removing for all PV
> devices by
Oleksandr Grytsov writes ("[PATCH v2 2/3] libxl: rename VKB backend type
"linux" to "pv""):
> From: Oleksandr Grytsov
>
> There are two kind of VKB backends: QEMU and user space PV backend.
> For PV backend "linux" enum is used but this name is confused. Rename
> "linux" enum to "pv" as it
> -Original Message-
> From: Xen-devel On Behalf Of Wei
> Liu
> Sent: 21 November 2019 19:51
> To: Xen Development List
> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> ; Michael Kelley ; Jan
> Beulich ; Roger Pau Monné
> Subject: [Xen-devel] [PATCH v4 8/8] x86: introduce CONFIG_HYPERV and
>
> -Original Message-
> From: Xen-devel On Behalf Of Wei
> Liu
> Sent: 21 November 2019 19:51
> To: Xen Development List
> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> ; Michael Kelley ; Jan
> Beulich ; Roger Pau Monné
> Subject: [Xen-devel] [PATCH v4 7/8] x86: be more verbose when running on
> -Original Message-
> From: Xen-devel On Behalf Of Wei
> Liu
> Sent: 21 November 2019 19:51
> To: Xen Development List
> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> ; Michael Kelley ; Jan
> Beulich ; Roger Pau Monné
> Subject: [Xen-devel] [PATCH v4 6/8] x86: switch xen guest implementation
> -Original Message-
> From: Xen-devel On Behalf Of Wei
> Liu
> Sent: 21 November 2019 19:51
> To: Xen Development List
> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> ; Michael Kelley ; Jan
> Beulich ; Roger Pau Monné
> Subject: [Xen-devel] [PATCH v4 5/8] x86: rename hypervisor_{alloc,
>
Currently if a user tries to live-load the same ucode revision that CPU
already has, he will get a single message in Xen log like:
(XEN) 128 cores are to update their microcode
No actual ucode loading will happen and this situation can be quite
confusing. Fix this by starting ucode update
> -Original Message-
> From: Xen-devel On Behalf Of Wei
> Liu
> Sent: 21 November 2019 19:51
> To: Xen Development List
> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> ; Michael Kelley ; Jan
> Beulich ; Roger Pau Monné
> Subject: [Xen-devel] [PATCH v4 4/8] x86: introduce hypervisor framework
On 22/11/2019 10:23, Roger Pau Monné wrote:
> On Thu, Nov 21, 2019 at 10:15:49PM +, Andrew Cooper wrote:
>> These patches want backporting due to the severity of patch 2. They should
>> therefore be considered for 4.13 at this point.
> Is there a matching XTF test to exercise this
On Thu, Nov 21, 2019 at 10:15:49PM +, Andrew Cooper wrote:
> These patches want backporting due to the severity of patch 2. They should
> therefore be considered for 4.13 at this point.
Is there a matching XTF test to exercise this functionality?
Thanks, Roger.
On 05.11.19 20:49, Andrew Cooper wrote:
The safety of livepatching depends on every stack having been unwound, but
there is one corner case where this is not true. The Sharing/Paging/Monitor
infrastructure may use waitqueues, which copy the stack frame sideways and
longjmp() to a different
flight 144239 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144239/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
144042
61 matches
Mail list logo
