flight 118275 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118275/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
On 23/01/18 07:34, Juergen Gross wrote:
> On 22/01/18 19:39, Andrew Cooper wrote:
>> On 22/01/18 16:51, Jan Beulich wrote:
>> On 22.01.18 at 16:00, wrote:
On 22/01/18 15:48, Jan Beulich wrote:
On 22.01.18 at 15:38, wrote:
>> On 22/01/18 15:22, Jan Beulich wrote:
>> O
On 22/01/18 22:45, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 22, 2018 at 01:32:44PM +0100, Juergen Gross wrote:
>> As a preparation for doing page table isolation in the Xen hypervisor
>> in order to mitigate "Meltdown" use dedicated stacks, GDT and TSS for
>> 64 bit PV domains mapped to the per-d
On 22/01/18 19:39, Andrew Cooper wrote:
> On 22/01/18 16:51, Jan Beulich wrote:
> On 22.01.18 at 16:00, wrote:
>>> On 22/01/18 15:48, Jan Beulich wrote:
>>> On 22.01.18 at 15:38, wrote:
> On 22/01/18 15:22, Jan Beulich wrote:
> On 22.01.18 at 15:18, wrote:
>>> On 22/01/18
On 22/01/18 17:51, Jan Beulich wrote:
On 22.01.18 at 16:00, wrote:
>> On 22/01/18 15:48, Jan Beulich wrote:
>> On 22.01.18 at 15:38, wrote:
On 22/01/18 15:22, Jan Beulich wrote:
On 22.01.18 at 15:18, wrote:
>> On 22/01/18 13:50, Jan Beulich wrote:
>> On 22.01.1
George Dunlap:
> Part of our solution to XSA-254 SP3 (aka "Meltdown") is to backport
> the PVH mode from 4.10 to 4.9 and 4.8. This will first allow people
> able to run PVH kernels to switch their PV guests directly to PVH
> guests; and second, eventually enable the backport of patches which
> wil
flight 118267 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118267/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair broken
test-amd64-i386-libvirt-xsm
flight 118270 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118270/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118253
test-armhf-armhf-libvirt 14 sav
On 01/22/2018 07:17 PM, Andrew Cooper wrote:
On 22/01/2018 22:27, Boris Ostrovsky wrote:
On 01/19/2018 08:36 AM, Andrew Cooper wrote:
On 19/01/18 11:43, Jan Beulich wrote:
@@ -99,6 +106,10 @@ UNLIKELY_END(realmode)
.Lvmx_vmentry_fail:
sti
SAVE_ALL
+
+SPEC_CTRL_
On Mon, Jan 22, 2018 at 01:32:44PM +0100, Juergen Gross wrote:
> As a preparation for doing page table isolation in the Xen hypervisor
> in order to mitigate "Meltdown" use dedicated stacks, GDT and TSS for
> 64 bit PV domains mapped to the per-domain virtual area.
>
> The per-vcpu stacks are used
flight 118268 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118268/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw broken
test-amd64-amd64-xl-p
On 23/01/2018 00:38, Stefano Stabellini wrote:
> On Tue, 23 Jan 2018, Andrew Cooper wrote:
>> On 22/01/2018 23:48, Stefano Stabellini wrote:
>>> Hi all,
>>>
>>> Running Xen inside QEMU x86 without KVM acceleartion and without VMX
>>> emulation leads to the failure appended below.
>>>
>>> This trivi
On Tue, 23 Jan 2018, Andrew Cooper wrote:
> On 22/01/2018 23:48, Stefano Stabellini wrote:
> > Hi all,
> >
> > Running Xen inside QEMU x86 without KVM acceleartion and without VMX
> > emulation leads to the failure appended below.
> >
> > This trivial workaround "fixes" the problem:
> >
> > diff --
When booting Xen via UEFI the Xen config file can contain multiple sections
each describing different boot options. It is currently only possible to choose
which section to boot with if the buffer contains a string. UEFI provides a
different standard to pass optional arguments to an application, an
On 22/01/2018 22:27, Boris Ostrovsky wrote:
> On 01/19/2018 08:36 AM, Andrew Cooper wrote:
>> On 19/01/18 11:43, Jan Beulich wrote:
>>
@@ -99,6 +106,10 @@ UNLIKELY_END(realmode)
.Lvmx_vmentry_fail:
sti
SAVE_ALL
+
+SPEC_CTRL_ENTRY_FROM_PV /* R
On 22/01/2018 23:48, Stefano Stabellini wrote:
> Hi all,
>
> Running Xen inside QEMU x86 without KVM acceleartion and without VMX
> emulation leads to the failure appended below.
>
> This trivial workaround "fixes" the problem:
>
> diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
> inde
Hi all,
Running Xen inside QEMU x86 without KVM acceleartion and without VMX
emulation leads to the failure appended below.
This trivial workaround "fixes" the problem:
diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
index 72f30d9..a67d6c1 100644
--- a/xen/arch/x86/extable.c
+++ b/x
flight 118269 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118269/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-amdbroken in 118264
test-amd64-amd64-xl-qemuu-debianhvm
On 01/19/2018 08:36 AM, Andrew Cooper wrote:
> On 19/01/18 11:43, Jan Beulich wrote:
>
>>> @@ -99,6 +106,10 @@ UNLIKELY_END(realmode)
>>> .Lvmx_vmentry_fail:
>>> sti
>>> SAVE_ALL
>>> +
>>> +SPEC_CTRL_ENTRY_FROM_PV /* Req: %rsp=regs/cpuinfo Clob: acd */
>> I think the use
Jan, All,
> On 10 Jan 2018, at 16:02, Jan Beulich wrote:
>
On 10.01.18 at 16:14, wrote:
>> In the early steps of compilation, the asm header files are created, such
>> as include/asm-$(TARGET_ARCH)/asm-offsets.h. These files depend on the
>> assembly file arch/$(TARGET_ARCH)/asm-offsets.s,
flight 118274 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118274/
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 1
On 22/01/18 18:48, George Dunlap wrote:
> On 01/22/2018 06:39 PM, Andrew Cooper wrote:
>> On 22/01/18 16:51, Jan Beulich wrote:
>> On 22.01.18 at 16:00, wrote:
On 22/01/18 15:48, Jan Beulich wrote:
On 22.01.18 at 15:38, wrote:
>> On 22/01/18 15:22, Jan Beulich wrote:
>>>
On 01/22/2018 06:39 PM, Andrew Cooper wrote:
> On 22/01/18 16:51, Jan Beulich wrote:
> On 22.01.18 at 16:00, wrote:
>>> On 22/01/18 15:48, Jan Beulich wrote:
>>> On 22.01.18 at 15:38, wrote:
> On 22/01/18 15:22, Jan Beulich wrote:
> On 22.01.18 at 15:18, wrote:
>>> On 22/
On 22/01/18 16:51, Jan Beulich wrote:
On 22.01.18 at 16:00, wrote:
>> On 22/01/18 15:48, Jan Beulich wrote:
>> On 22.01.18 at 15:38, wrote:
On 22/01/18 15:22, Jan Beulich wrote:
On 22.01.18 at 15:18, wrote:
>> On 22/01/18 13:50, Jan Beulich wrote:
>> On 22.01.1
On Mon, Jan 22, 2018 at 06:19:43PM +, Andrew Cooper wrote:
> On 22/01/18 18:17, Wei Liu wrote:
> > On Mon, Jan 22, 2018 at 06:09:14PM +, Andrew Cooper wrote:
> >> On 22/01/18 16:13, Wei Liu wrote:
> >>> Modify early boot code to relocate pvh info as well, so that we can be
> >>> sure __va i
On 22/01/18 18:17, Wei Liu wrote:
> On Mon, Jan 22, 2018 at 06:09:14PM +, Andrew Cooper wrote:
>> On 22/01/18 16:13, Wei Liu wrote:
>>> Modify early boot code to relocate pvh info as well, so that we can be
>>> sure __va in __start_xen works.
>>>
>>> Signed-off-by: Wei Liu
>>> ---
>>> Cc: Jan
There are Device Tree (e.g for the Foundation Model) out that describes the
ITS but LPIs is not supported by the platform. Booting with such DT will
result to an early Data Abort. The same DT is booting fine with a
baremetal Linux because ITS will be initialized only when LPIs is
supported.
While
There are firmware tables out describing the ITS but does not support
LPIs. This will result to a data abort when trying to initialize ITS.
While this can be consider a bug in the Device-Tree, same configuration
boots on Linux. So gate the ITS initialization with the support of LPIs
in the distrib
Hi all,
This small patch series fix an issue I discovered when using the Foundation
model and the DT provided by Linux upstream.
Indeed the Device-Tree is exposing an ITS but LPIs are not available.
Resulting to an early crash on Xen.
Whilst this looks a DT issue, Linux is able to cope with it.
On 22/01/18 16:13, Wei Liu wrote:
> Modify early boot code to relocate pvh info as well, so that we can be
> sure __va in __start_xen works.
>
> Signed-off-by: Wei Liu
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Roger Pau Monné
> Cc: Doug Goldstein
>
> v4: inlcude autoconf.h directly. Th
On Mon, Jan 22, 2018 at 06:09:14PM +, Andrew Cooper wrote:
> On 22/01/18 16:13, Wei Liu wrote:
> > Modify early boot code to relocate pvh info as well, so that we can be
> > sure __va in __start_xen works.
> >
> > Signed-off-by: Wei Liu
> > ---
> > Cc: Jan Beulich
> > Cc: Andrew Cooper
> > C
flight 118271 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118271/
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 1
On Mon, 22 Jan 2018, Julien Grall wrote:
> The include percpu.h was added by mistake in cpuerrata.h (see commit
> 4c4fddc166 "xen/arm64: Add skeleton to harden the branch aliasing
> attacks"). So remove it.
>
> Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> xen/include/as
On Mon, Jan 22, 2018 at 06:28:17PM +0100, msd+xen-de...@msd.im wrote:
> Hi,
>
> I only see 1 CPU core on Xen 4.9 when booted via grub instead of 8.
>
> It's may be related to :
> - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820807
> - https://xenproject.atlassian.net/browse/XEN-42
>
> It
On Fri, Jan 19, 2018 at 03:43:26PM +, George Dunlap wrote:
[...]
> But there will surely be more attacks like this (in fact, there may
> already be some in the works[2]).
[...]
> -George
>
> [1] https://lwn.net/SubscriberLink/744287/02dd9bc503409ca3/
> [2] skyfallattack.com
In case anyo
Hi,
I only see 1 CPU core on Xen 4.9 when booted via grub instead of 8.
It's may be related to :
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820807
- https://xenproject.atlassian.net/browse/XEN-42
It is the first server on which I have this problem.
I can confirm that :
- if I boot Deb
On 01/22/2018 05:04 PM, Jan Beulich wrote:
On 22.01.18 at 16:15, wrote:
>> On 01/22/2018 01:30 PM, Jan Beulich wrote:
>> On 22.01.18 at 13:33, wrote:
What I'm proposing is something like this:
* We have a "global" region of Xen memory that is mapped by all
processors.
On 22/01/18 16:49, Jan Beulich wrote:
On 22.01.18 at 16:51, wrote:
>> On 19/01/18 15:02, Jan Beulich wrote:
>> On 19.01.18 at 15:24, wrote:
On 19/01/18 12:47, Jan Beulich wrote:
On 18.01.18 at 16:46, wrote:
>> + * %rsp is preserved by using an extra GPR because a) we'v
>>> On 22.01.18 at 16:15, wrote:
> On 01/22/2018 01:30 PM, Jan Beulich wrote:
> On 22.01.18 at 13:33, wrote:
>>> What I'm proposing is something like this:
>>>
>>> * We have a "global" region of Xen memory that is mapped by all
>>> processors. This will contain everything we consider not sen
>>> On 22.01.18 at 17:13, wrote:
> Modify early boot code to relocate pvh info as well, so that we can be
> sure __va in __start_xen works.
>
> Signed-off-by: Wei Liu
As before
Reviewed-by: Jan Beulich
with the caveat that this shouldn't go in without Andrew
withdrawing his general objection.
>>> On 22.01.18 at 17:33, wrote:
> On Mon, Jan 22, 2018 at 04:28:30PM +, Wei Liu wrote:
>> It used to the case that we placed RSDP under 1MB and let Xen search
>> for it. We moved the placement to under 4GB in 4a5733771, so the
>> search wouldn't work.
>>
>> Introduce rsdp_hint to ACPI code a
>>> On 22.01.18 at 16:00, wrote:
> On 22/01/18 15:48, Jan Beulich wrote:
> On 22.01.18 at 15:38, wrote:
>>> On 22/01/18 15:22, Jan Beulich wrote:
>>> On 22.01.18 at 15:18, wrote:
> On 22/01/18 13:50, Jan Beulich wrote:
> On 22.01.18 at 13:32, wrote:
>>> As a preparation
>>> On 22.01.18 at 16:51, wrote:
> On 19/01/18 15:02, Jan Beulich wrote:
> On 19.01.18 at 15:24, wrote:
>>> On 19/01/18 12:47, Jan Beulich wrote:
>>> On 18.01.18 at 16:46, wrote:
> + * %rsp is preserved by using an extra GPR because a) we've got plenty
> spare,
> + * b) the
On Mon, Jan 22, 2018 at 04:28:30PM +, Wei Liu wrote:
> It used to the case that we placed RSDP under 1MB and let Xen search
> for it. We moved the placement to under 4GB in 4a5733771, so the
> search wouldn't work.
>
> Introduce rsdp_hint to ACPI code and set that variable in
> convert_pvh_inf
osstest service owner writes ("[xen-unstable test] 118266: regressions -
trouble: broken/fail/pass"):
> flight 118266 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/118266/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which
It used to the case that we placed RSDP under 1MB and let Xen search
for it. We moved the placement to under 4GB in 4a5733771, so the
search wouldn't work.
Introduce rsdp_hint to ACPI code and set that variable in
convert_pvh_info.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
C
flight 118266 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118266/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu broken
test-amd64-amd64-xl-qemut-win7-amd64
Modify early boot code to relocate pvh info as well, so that we can be
sure __va in __start_xen works.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Roger Pau Monné
Cc: Doug Goldstein
v4: inlcude autoconf.h directly. The code itself is unchanged.
---
xen/arch/x86/boot/Mak
>>> On 22.01.18 at 16:34, wrote:
> On Mon, Jan 22, 2018 at 03:02:52PM +, Wei Liu wrote:
>> --- a/xen/drivers/acpi/osl.c
>> +++ b/xen/drivers/acpi/osl.c
>> @@ -62,8 +62,13 @@ void __init acpi_os_vprintf(const char *fmt, va_list args)
>> printk("%s", buffer);
>> }
>>
>> +acpi_physical_ad
On 19/01/18 15:02, Jan Beulich wrote:
On 19.01.18 at 15:24, wrote:
>> On 19/01/18 12:47, Jan Beulich wrote:
>> On 18.01.18 at 16:46, wrote:
@@ -265,6 +265,10 @@ On hardware supporting IBRS, the `ibrs=` option can
be
used to force or
prevent Xen using the feature it
On Mon, Jan 22, 2018 at 03:02:52PM +, Wei Liu wrote:
> diff --git a/xen/arch/x86/guest/pvh-boot.c b/xen/arch/x86/guest/pvh-boot.c
> index be3122b16c..2903b392bc 100644
> --- a/xen/arch/x86/guest/pvh-boot.c
> +++ b/xen/arch/x86/guest/pvh-boot.c
> @@ -69,6 +69,8 @@ static void __init convert_pvh_
Roger Pau Monné writes ("Re: [Xen-devel] [PATCH v2 4/7] x86/shim: use credit
scheduler"):
> On Fri, Jan 19, 2018 at 03:34:55PM +, Wei Liu wrote:
> > Remove sched=null from shim cmdline and doc
> >
> > We use the default scheduler (credit1 as of writing). The NULL
> > scheduler still has bugs
On 19/01/18 14:01, Jan Beulich wrote:
On 18.01.18 at 16:46, wrote:
>> +/* Calculate whether Retpoline is known-safe on this CPU. */
>> +static bool __init retpoline_safe(void)
>> +{
>> +unsigned int ucode_rev = this_cpu(ucode_cpu_info).cpu_sig.rev;
>> +
>> +if ( boot_cpu_data.x86_vend
On 01/22/2018 01:30 PM, Jan Beulich wrote:
On 22.01.18 at 13:33, wrote:
>> On 01/22/2018 09:25 AM, Jan Beulich wrote:
>> On 19.01.18 at 18:00, wrote:
On 01/19/2018 04:36 PM, Jan Beulich wrote:
On 19.01.18 at 16:43, wrote:
>> So what if instead of trying to close the "w
It used to the case that we placed RSDP under 1MB and let Xen search
for it. We moved the placement to under 4GB in 4a5733771, so the
search wouldn't work.
Introduce rsdp_hint to ACPI code and set that variable in
convert_pvh_info.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
C
On 22/01/18 15:48, Jan Beulich wrote:
On 22.01.18 at 15:38, wrote:
>> On 22/01/18 15:22, Jan Beulich wrote:
>> On 22.01.18 at 15:18, wrote:
On 22/01/18 13:50, Jan Beulich wrote:
On 22.01.18 at 13:32, wrote:
>> As a preparation for doing page table isolation in the Xen
On Mon, Jan 22, 2018 at 05:58:24AM -0700, Jan Beulich wrote:
> >>> On 22.01.18 at 13:48, wrote:
> > I think the proper way to solve this is to reset the mask bits to
> > masked when the vector is unbound, so that at bind time the state of
> > the mask is consistent regardless of whether the vector
On 19/01/18 10:45, Jan Beulich wrote:
On 18.01.18 at 16:46, wrote:
>> @@ -153,14 +168,44 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t
>> val)
>> {
>> const struct vcpu *curr = current;
>> struct domain *d = v->domain;
>> +const struct cpuid_policy *cp = d->arch.cp
>>> On 22.01.18 at 15:38, wrote:
> On 22/01/18 15:22, Jan Beulich wrote:
> On 22.01.18 at 15:18, wrote:
>>> On 22/01/18 13:50, Jan Beulich wrote:
>>> On 22.01.18 at 13:32, wrote:
> As a preparation for doing page table isolation in the Xen hypervisor
> in order to mitigate "Meltd
On 22/01/18 15:22, Jan Beulich wrote:
On 22.01.18 at 15:18, wrote:
>> On 22/01/18 13:50, Jan Beulich wrote:
>> On 22.01.18 at 13:32, wrote:
As a preparation for doing page table isolation in the Xen hypervisor
in order to mitigate "Meltdown" use dedicated stacks, GDT and TSS fo
The include percpu.h was added by mistake in cpuerrata.h (see commit
4c4fddc166 "xen/arm64: Add skeleton to harden the branch aliasing
attacks"). So remove it.
Signed-off-by: Julien Grall
---
xen/include/asm-arm/cpuerrata.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/include/asm-arm/c
>>> On 22.01.18 at 15:25, wrote:
> On 22/01/18 14:10, Juergen Gross wrote:
>> On 22/01/18 13:52, Jan Beulich wrote:
>> On 22.01.18 at 13:32, wrote:
Remove NSC/Cyrix CPU macros and current_text_addr() which are used
nowhere.
>>> I agree doing the former, but I have a vague recollecti
On 22/01/18 14:10, Juergen Gross wrote:
> On 22/01/18 13:52, Jan Beulich wrote:
> On 22.01.18 at 13:32, wrote:
>>> Remove NSC/Cyrix CPU macros and current_text_addr() which are used
>>> nowhere.
>> I agree doing the former, but I have a vague recollection that we've
>> left the latter in place
>>> On 22.01.18 at 15:18, wrote:
> On 22/01/18 13:50, Jan Beulich wrote:
> On 22.01.18 at 13:32, wrote:
>>> As a preparation for doing page table isolation in the Xen hypervisor
>>> in order to mitigate "Meltdown" use dedicated stacks, GDT and TSS for
>>> 64 bit PV domains mapped to the per-d
On 22/01/18 13:50, Jan Beulich wrote:
On 22.01.18 at 13:32, wrote:
>> As a preparation for doing page table isolation in the Xen hypervisor
>> in order to mitigate "Meltdown" use dedicated stacks, GDT and TSS for
>> 64 bit PV domains mapped to the per-domain virtual area.
>>
>> The per-vcpu s
On 22/01/18 13:52, Jan Beulich wrote:
On 22.01.18 at 13:32, wrote:
>> Remove NSC/Cyrix CPU macros and current_text_addr() which are used
>> nowhere.
>
> I agree doing the former, but I have a vague recollection that we've
> left the latter in place despite there not being any callers at pres
On 22/01/18 12:06, Jan Beulich wrote:
On 22.01.18 at 12:42, wrote:
>> On 19/01/18 13:51, Jan Beulich wrote:
>> On 19.01.18 at 14:36, wrote:
On 19/01/18 11:43, Jan Beulich wrote:
On 18.01.18 at 16:46, wrote:
>> @@ -729,6 +760,9 @@ ENTRY(nmi)
>> handle_ist_exception
On Mon, Jan 22, 2018 at 06:35:14AM -0700, Jan Beulich wrote:
> >>> On 22.01.18 at 14:21, wrote:
> > On Mon, Jan 22, 2018 at 01:03:14PM +, Roger Pau Monné wrote:
> >> On Mon, Jan 22, 2018 at 12:47:10PM +, Wei Liu wrote:
> >> > --- a/xen/drivers/acpi/osl.c
> >> > +++ b/xen/drivers/acpi/osl.c
Hi,
On 19/01/18 06:10, Manish Jaggi wrote:
On 01/17/2018 12:22 AM, Julien Grall wrote:
IORT for hardware domain is generated using the requesterId and
deviceId map.
Signed-off-by: Manish Jaggi
---
xen/arch/arm/domain_build.c | 12 -
xen/drivers/acpi/arm/Makefile | 1 +
>>> On 22.01.18 at 14:29, wrote:
> On 22/01/18 13:01, Jan Beulich wrote:
> On 22.01.18 at 13:52, wrote:
>>> On 22/01/18 12:41, Jan Beulich wrote:
>>> On 19.01.18 at 20:19, wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -1117,7 +1117,7 @@ s
Hi,
On 22/01/18 05:07, Manish Jaggi wrote:
On 01/19/2018 05:33 PM, Julien Grall wrote:
On 19/01/18 06:05, Manish Jaggi wrote:
On 01/17/2018 12:01 AM, Julien Grall wrote:
Hi Manish,
Hi Julien,
Thanks for reviewing the patch.
I sent the previous e-mail too soon.
On 02/01/18 09:27, manis
>>> On 22.01.18 at 14:21, wrote:
> On Mon, Jan 22, 2018 at 01:03:14PM +, Roger Pau Monné wrote:
>> On Mon, Jan 22, 2018 at 12:47:10PM +, Wei Liu wrote:
>> > --- a/xen/drivers/acpi/osl.c
>> > +++ b/xen/drivers/acpi/osl.c
>> > @@ -38,6 +38,10 @@
>> > #include
>> > #include
>> >
>> > +#
>>> On 22.01.18 at 13:33, wrote:
> On 01/22/2018 09:25 AM, Jan Beulich wrote:
> On 19.01.18 at 18:00, wrote:
>>> On 01/19/2018 04:36 PM, Jan Beulich wrote:
>>> On 19.01.18 at 16:43, wrote:
> So what if instead of trying to close the "windows", we made it so that
> there was nothi
On 22/01/18 13:01, Jan Beulich wrote:
On 22.01.18 at 13:52, wrote:
>> On 22/01/18 12:41, Jan Beulich wrote:
>> On 19.01.18 at 20:19, wrote:
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1117,7 +1117,7 @@ struct xen_domctl {
#define XEN_DOMCT
On Mon, Jan 22, 2018 at 01:03:14PM +, Roger Pau Monné wrote:
> On Mon, Jan 22, 2018 at 12:47:10PM +, Wei Liu wrote:
> > It used to the case that we placed RSDP under 1MB and let Xen search
> > for it. We moved the placement to under 4GB in 4a5733771, so the
> > search wouldn't work.
> >
>
On Mon, Jan 22, 2018 at 12:47:10PM +, Wei Liu wrote:
> It used to the case that we placed RSDP under 1MB and let Xen search
> for it. We moved the placement to under 4GB in 4a5733771, so the
> search wouldn't work.
>
> Stash the RSDP address to solve this problem.
>
> Suggested-by: Roger Pau
>>> On 22.01.18 at 13:52, wrote:
> On 22/01/18 12:41, Jan Beulich wrote:
> On 19.01.18 at 20:19, wrote:
>>> --- a/xen/include/public/domctl.h
>>> +++ b/xen/include/public/domctl.h
>>> @@ -1117,7 +1117,7 @@ struct xen_domctl {
>>> #define XEN_DOMCTL_pausedomain3
>>> #defi
>>> On 22.01.18 at 13:48, wrote:
> I think the proper way to solve this is to reset the mask bits to
> masked when the vector is unbound, so that at bind time the state of
> the mask is consistent regardless of whether the vector has been
> previously bound or not. The following patch should fix t
>>> On 22.01.18 at 13:35, wrote:
> To avoid spamming the list with all the other acked patches, here is the
> updated patch.
Feel free to re-instate my R-b, but please commit only if Andrew
withdraws his earlier voiced more general objection.
Jan
___
>>> On 22.01.18 at 13:32, wrote:
> Remove NSC/Cyrix CPU macros and current_text_addr() which are used
> nowhere.
I agree doing the former, but I have a vague recollection that we've
left the latter in place despite there not being any callers at present.
Jan
___
On 22/01/18 12:41, Jan Beulich wrote:
On 19.01.18 at 20:19, wrote:
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -1117,7 +1117,7 @@ struct xen_domctl {
>> #define XEN_DOMCTL_pausedomain3
>> #define XEN_DOMCTL_unpausedomain
>>> On 22.01.18 at 13:32, wrote:
> As a preparation for doing page table isolation in the Xen hypervisor
> in order to mitigate "Meltdown" use dedicated stacks, GDT and TSS for
> 64 bit PV domains mapped to the per-domain virtual area.
>
> The per-vcpu stacks are used for early interrupt handling
On Fri, Dec 15, 2017 at 05:07:06AM -0700, Jan Beulich wrote:
> >>> On 18.10.17 at 13:40, wrote:
> > +static void control_write(const struct pci_dev *pdev, unsigned int reg,
> > + uint32_t val, void *data)
> > +{
> > +struct vpci_msi *msi = data;
> > +unsigned int v
It used to the case that we placed RSDP under 1MB and let Xen search
for it. We moved the placement to under 4GB in 4a5733771, so the
search wouldn't work.
Stash the RSDP address to solve this problem.
Suggested-by: Roger Pau Monné
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
On Mon, Jan 22, 2018 at 12:44:41PM +, Roger Pau Monné wrote:
> On Mon, Jan 22, 2018 at 12:35:21PM +, Wei Liu wrote:
> > To avoid spamming the list with all the other acked patches, here is the
> > updated patch.
> >
> > ---8<---
> > From 1ac0afbbc0ecd620c5fba3a03bb084bc4dafc78e Mon Sep 17
On Mon, Jan 22, 2018 at 12:35:21PM +, Wei Liu wrote:
> To avoid spamming the list with all the other acked patches, here is the
> updated patch.
>
> ---8<---
> From 1ac0afbbc0ecd620c5fba3a03bb084bc4dafc78e Mon Sep 17 00:00:00 2001
> From: Wei Liu
> Date: Wed, 17 Jan 2018 18:38:02 +
> Subj
>>> On 19.01.18 at 20:19, wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -1117,7 +1117,7 @@ struct xen_domctl {
> #define XEN_DOMCTL_pausedomain3
> #define XEN_DOMCTL_unpausedomain 4
> #define XEN_DOMCTL_getdomaininfo
Add a command line parameter for controlling Xen page table isolation
(XPTI): per default it is on for non-AMD systems in 64 bit pv domains.
Possible settings are:
- true: switched on even on AMD systems
- false: switched off for all
- nodom0: switched off for dom0
Signed-off-by: Juergen Gross
-
The only difference between all the DEFINE_TRAP_ENTRY_* macros are the
interrupts (Asynchronous Abort, IRQ, FIQ) unmasked.
Rather than duplicating the code, introduce __DEFINE_TRAP_ENTRY macro
that will take the list of interrupts to unmask.
This is part of XSA-254.
Signed-off-by: Julien Grall
In case of XPTI being active for a pv-domain allocate and initialize
per-vcpu stacks. The stacks are added to the per-domain mappings of
the pv-domain.
Signed-off-by: Juergen Gross
---
xen/arch/x86/pv/domain.c | 72 +++
xen/include/asm-x86/config.h |
On Mon, Jan 22, 2018 at 03:31:22AM -0700, Jan Beulich wrote:
> >>> On 19.01.18 at 17:39, wrote:
> > On Fri, Jan 19, 2018 at 04:29:31PM +, Roger Pau Monné wrote:
> >> On Fri, Jan 19, 2018 at 03:34:56PM +, Wei Liu wrote:
> >> > diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/bu
Modify the interrupt handlers to switch stacks on interrupt entry in
case they are running on a per-vcpu stack. Same applies to returning
to the guest: in case the to be loaded context is located on a
per-vcpu stack switch to this one before returning to the guest.
Signed-off-by: Juergen Gross
--
Revert patch "x86: Meltdown band-aid against malicious 64-bit PV
guests" in order to prepare for a final Meltdown mitigation.
Signed-off-by: Juergen Gross
---
xen/arch/x86/domain.c | 5 -
xen/arch/x86/mm.c | 21
xen/arch/x86/smpboot.c | 200 -
In order to support switching stacks when entering the hypervisor for
support of page table isolation, don't use %rsp for accessing the
saved user registers, but do that via %rdi.
Signed-off-by: Juergen Gross
---
xen/arch/x86/x86_64/compat/entry.S | 82 +--
xen/arch/x86/x86_
On 01/22/2018 09:25 AM, Jan Beulich wrote:
On 19.01.18 at 18:00, wrote:
>> On 01/19/2018 04:36 PM, Jan Beulich wrote:
>> On 19.01.18 at 16:43, wrote:
So what if instead of trying to close the "windows", we made it so that
there was nothing through the windows to see? If no mat
Remove NSC/Cyrix CPU macros and current_text_addr() which are used
nowhere.
Signed-off-by: Juergen Gross
---
xen/include/asm-x86/processor.h | 41 -
1 file changed, 41 deletions(-)
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/process
When scheduling a vcpu subject to xpti activate the per-vcpu stacks
by loading the vcpu specific gdt and tss. When de-scheduling such a
vcpu switch back to the per physical cpu gdt and tss.
Accessing the user registers on the stack is done via helpers as
depending on XPTI active or not the registe
show_guest_stack() and compat_show_guest_stack() stop dumping the
stack of the guest whenever its virtual address reaches the same
alignment which is used for the hypervisor stacks.
Remove this arbitrary limit and try to dump a fixed number of lines
instead.
Signed-off-by: Juergen Gross
---
xen
For support of per-vcpu stacks we need per-vcpu trampolines. To be
able to put those into the per-domain mappings the upper levels
page tables must not have NX set for per-domain mappings.
In order to be able to reset the NX bit for a per-domain mapping add
a helper flipflags_perdomain_mapping() f
Carve out the TSS initialization from load_system_tables().
Signed-off-by: Juergen Gross
---
xen/arch/x86/cpu/common.c| 56
xen/include/asm-x86/system.h | 1 +
2 files changed, 32 insertions(+), 25 deletions(-)
diff --git a/xen/arch/x86/cpu/comm
1 - 100 of 130 matches
Mail list logo
