On Thu, Oct 31, 2019 at 07:38:08PM +, Andrew Cooper wrote:
> PTF_* are declared within CONFIG_PV, and used outside:
>
> mm.c: In function ‘_put_page_type’:
> mm.c:2819:32: error: ‘PTF_preemptible’ undeclared (first use in this
> function)
>bool preemptible = flags &
Hi,
On 31/10/2019 19:28, Andrew Cooper wrote:
> This code is especially tangled. VCPUOP_initialise calls into
> arch_initialise_vcpu() which calls back into default_initialise_vcpu() which
> is common code.
>
> This path is actually dead code on ARM, because VCPUOP_initialise is filtered
> out
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf
On 31/10/2019 11:15, Jan Beulich wrote:
> On 30.10.2019 23:21, Sander Eikelenboom wrote:
>> Call trace seems to be the same in all cases.
>>
>> --
>> Sander
>>
>>
>> (XEN) [2019-10-30 22:07:05.748] AMD-Vi: update_paging_mode Try to access
>> pdev_list without aquiring pcidevs_lock.
>> (XEN)
flight 143478 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143478/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
PTF_* are declared within CONFIG_PV, and used outside:
mm.c: In function ‘_put_page_type’:
mm.c:2819:32: error: ‘PTF_preemptible’ undeclared (first use in this function)
bool preemptible = flags & PTF_preemptible;
^~~
mm.c:2819:32: note:
This code is especially tangled. VCPUOP_initialise calls into
arch_initialise_vcpu() which calls back into default_initialise_vcpu() which
is common code.
This path is actually dead code on ARM, because VCPUOP_initialise is filtered
out by do_arm_vcpu_op().
The only valid way to start a
On Thu, Oct 31, 2019 at 12:58:29PM +0100, Roger Pau Monne wrote:
> The event channel data was not copied back to guest memory, fix this
> by doing the copy.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Wei Liu
___
Xen-devel mailing list
On Wed, Oct 30, 2019 at 02:54:47PM +, Sergey Dyasli wrote:
> Converting a guest from PV to PV-in-PVH makes the guest to have 384k
> less memory, which may confuse guest's balloon driver. This happens
> because Xen unconditionally reserves 640k - 1M region in E820 despite
> the fact that it's
flight 143391 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143391/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 12 guest-start fail REGR. vs. 143023
On Thu, 31 Oct 2019, Julien Grall wrote:
> When a SError/Asynchronous Abort generated by the guest has been
> consumed, we will skip the handling of the initial exception.
>
> This includes the calls to enter_hypervisor_from_guest{, _noirq} that
> is used to synchronize part of the guest state
On Thu, 31 Oct 2019, Julien Grall wrote:
> At the moment, SSBD workaround is re-enabled for Xen after interrupts
> are unmasked. This means we may end up to execute some part of the
> hypervisor if an interrupt is received before the workaround is
> re-enabled.
>
> Each trap may require to unmask
flight 143397 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143397/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501
Tests which did
The default for d-i, if it doesn't know better, is to let update-grub
set grub's terminal to `gfxterm'. But in osstest we do not really
ever want to use a graphical console.
Let us discuss some of the cases in a bit more detail:
On UEFI systems with a serial console, the UEFI console ought (and
flight 143378 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143378/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 18 guest-start/debian.repeat fail REGR. vs. 143158
On Thu, Oct 31, 2019 at 07:52:23AM -0700, Joe Jin wrote:
> On 10/31/19 1:01 AM, Jan Beulich wrote:
> > On 30.10.2019 19:01, Joe Jin wrote:
> >> On 10/30/19 10:23 AM, Roger Pau Monné wrote:
> >>> On Wed, Oct 30, 2019 at 09:38:16AM -0700, Joe Jin wrote:
> On 10/30/19 1:24 AM, Roger Pau Monné
On 10/31/19 7:56 AM, Jan Beulich wrote:
> On 31.10.2019 15:52, Joe Jin wrote:
>> On 10/31/19 1:01 AM, Jan Beulich wrote:
>>> On 30.10.2019 19:01, Joe Jin wrote:
On 10/30/19 10:23 AM, Roger Pau Monné wrote:
> On Wed, Oct 30, 2019 at 09:38:16AM -0700, Joe Jin wrote:
>> On 10/30/19 1:24
The macro SYNCHRONIZE_SERROR() has an assert to check whether it will
be called with Abort interrupt unmasked. However, this is only done if
a given cap is not enabled.
None of the callers will treat the abort interrupt differently
depending on a feature. Furthermore, it makes more difficult to
When a SError/Asynchronous Abort generated by the guest has been
consumed, we will skip the handling of the initial exception.
This includes the calls to enter_hypervisor_from_guest{, _noirq} that
is used to synchronize part of the guest state with the internal
representation and re-enable
At the moment, enter_hypervisor_head() and leave_hypervisor_tail() are
used to deal with actions to be done before/after any guest request is
handled.
While they are meant to work in pair, the former is called for most of
the traps, including traps from the same exception level (i.e.
hypervisor)
From: Mark Rutland
In some cases, one side of an alternative sequence is simply a number of
NOPs used to balance the other side. Keeping track of this manually is
tedious, and the presence of large chains of NOPs makes the code more
painful to read than necessary.
To ameliorate matters, this
At the moment, ARCH_PATCH_INSN_SIZE is defined in the header
livepatch.h. However, this is also used in the alternative code.
Rather than including livepatch.h just for using the define, move it in
the header insn.h which seems more suitable.
Signed-off-by: Julien Grall
Reviewed-by: Volodymyr
When serrors=diverse is selected by the user, we will only synchronize
the pending SErrors on entry to hypervisor from guest context and exit
from guest to hypervisor context.
We don't need synchronize SErrors between guest context switch as they
would be categorized to Hypervisor generated
The macro alternative_if_not_cap is taking two parameters. The second
parameter is never used and it is hard to see how this can be used
correctly as it is only protecting the alternative section magic.
Signed-off-by: Julien Grall
Reviewed-by: Volodymyr Babchuk
Acked-by: Stefano Stabellini
Per the Arm ARM (D4.5 in ARM DDI 0487E.a), SError may be precise or
imprecise.
Imprecise means the state presented to the exception handler is not
guaranteed to be consistent with any point in the excution stream from
which the exception was taken. In other words, they are likely to be
fatal as
Hi all,
This is v4 of the series. For those wondering why it is v4 and not v2, this
series is closely related to XSA-303 [1] and refrained to post a new version
publicly. To avoid delaying the series was reviewed privately on security@.
The series is now nearly fully reviewed. There are just a
When injecting a virtual Abort to the guest, we want to update the guest
PC so it can re-execute the HVC/SMC once it has handled the SError.
This is unfortunately not the case when the SError is synchronized on
entry from the guest. As the SError will be received while running in
hypervisor
At the moment, SSBD workaround is re-enabled for Xen after interrupts
are unmasked. This means we may end up to execute some part of the
hypervisor if an interrupt is received before the workaround is
re-enabled.
Each trap may require to unmask different interrupts.
As the rest of
Most of the guest vectors are using the same pattern. This makes fairly
tedious to alter the pattern and risk introducing mistakes when updating
each path.
A new macro is introduced to generate the guest vectors and now use it
in the one that use the open-code version.
Signed-off-by: Julien
At the moment, when we receive an SError exception from the guest, we
don't check if there are any other pending. For hardening the code, we
should ensure any pending SError are accounted to the guest before
executing any code with SError unmasked.
The recently introduced macro 'guest_vector'
serrors= only supports 3 values "diverse", "forward" and "panic".
The current implementation of parse_serrors_behavior() will default to
"diverse" for any invalid value and not tell the users.
Rather than ignore the invalid input, return an error to the caller so
it can decides the be approach.
A follow-up patch will require to include insn.h from assembly code. So
we need to protect any C-specific definition to avoid compilation
errors when used in assembly code.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v3:
- Add Stefano's reviewed-by
Using alternative_if makes the code a bit more streamlined.
Take the opportunity to use the new auto-nop infrastructure to avoid
counting the number of nop in the else part for arch/arm/arm64/entry.S
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
This is pretty much a
At the moment, the interrupts to mask/unmask are hardcoded in the code
making more difficult to find out what's going on.
A new series of short-hand specific to the file entry.S is now added.
The name of the short-hands should tell which interrupts will be
changed by the msr daif{set, clr}
The documentation on top of __do_serror() is trying to describe all the
possibilities to receive an SErrors.
The description of type#2 is quite misleading because receiving an
SError in EL2 after unmasking SError interrupt ({PSTATE, CPSR}.A) does
not necessarily imply the SError were generated by
The current documentation is misleading for a few reasons:
1) The synchronization happens on all exit/entry from/to the guest.
This includes from EL0 (i.e userspace).
2) Trusted guest can also generate SErrors (e.g. memory failure)
3) Without RAS support, SErrors are IMP
The function save_guest_regs() is doing more than saving guest
registers. It also restore the vectors table and consume any pending
SErrors generated by the guest. So rename the function to
arch_enter_hypervisor_from_guest_preirq().
Take the opportunity to use ENDPROC() for the benefits of static
On 31.10.2019 15:52, Joe Jin wrote:
> On 10/31/19 1:01 AM, Jan Beulich wrote:
>> On 30.10.2019 19:01, Joe Jin wrote:
>>> On 10/30/19 10:23 AM, Roger Pau Monné wrote:
On Wed, Oct 30, 2019 at 09:38:16AM -0700, Joe Jin wrote:
> On 10/30/19 1:24 AM, Roger Pau Monné wrote:
>> Can you try
On 10/31/19 1:01 AM, Jan Beulich wrote:
> On 30.10.2019 19:01, Joe Jin wrote:
>> On 10/30/19 10:23 AM, Roger Pau Monné wrote:
>>> On Wed, Oct 30, 2019 at 09:38:16AM -0700, Joe Jin wrote:
On 10/30/19 1:24 AM, Roger Pau Monné wrote:
> Can you try to add the following debug patch on top of
flight 143371 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143371/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl 12 guest-start fail REGR. vs. 143190
On 31/10/2019 11:07, Jan Beulich wrote:
> On 31.10.2019 11:56, Sergey Dyasli wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -274,6 +274,15 @@ static inline u32 phys_pkg_id(u32 cpuid_apic, int
>> index_msb)
>> return _phys_pkg_id(get_apic_id(), index_msb);
On 31.10.2019 12:45, Sergey Dyasli wrote:
> On 31/10/2019 11:07, Jan Beulich wrote:
>> On 31.10.2019 11:56, Sergey Dyasli wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -5943,7 +5943,7 @@ const struct platform_bad_page *__init
>>> get_platform_badpages(unsigned int *array
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-18422 / XSA-303
version 4
ARM: Interrupts are unconditionally unmasked in exception handlers
UPDATES IN VERSION 4
Fix typoes in the series and add
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-18424 / XSA-302
version 5
passed through PCI devices may corrupt host memory after deassignment
UPDATES IN VERSION 5
Public release.
The patches are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-18423 / XSA-301
version 3
add-to-physmap can be abused to DoS Arm hosts
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-18420 / XSA-296
version 4
VCPUOP_initialise DoS
UPDATES IN VERSION 4
Public release.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-18425 / XSA-298
version 3
missing descriptor table limit checking in x86 PV emulation
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
After sending the 'device_del' command for a PCI passthrough device,
we wait until QEMU has effectively deleted the device, this involves
executing more QMP commands. While waiting, libxl hold the connection.
It isn't necessary to hold the connection and it prevents others from
making progress,
The event channel data was not copied back to guest memory, fix this
by doing the copy.
Signed-off-by: Roger Pau Monné
---
Cc: Juergen Gross
---
xen/arch/x86/pv/shim.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index
On 31/10/2019 11:07, Jan Beulich wrote:
> On 31.10.2019 11:56, Sergey Dyasli wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -274,6 +274,15 @@ static inline u32 phys_pkg_id(u32 cpuid_apic, int
>> index_msb)
>> return _phys_pkg_id(get_apic_id(), index_msb);
On 31.10.2019 11:56, Sergey Dyasli wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -274,6 +274,15 @@ static inline u32 phys_pkg_id(u32 cpuid_apic, int
> index_msb)
> return _phys_pkg_id(get_apic_id(), index_msb);
> }
>
> +/*
> + * Sometimes it's too early
Converting a guest from PV to PV-in-PVH makes the guest to have 384k
less memory, which may confuse guest's balloon driver. This happens
because Xen unconditionally reserves 640k - 1M region in E820 despite
the fact that it's really a usable RAM in PVH boot mode.
Fix this by skipping region type
flight 143363 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143363/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-boot fail REGR. vs. 133580
flight 143365 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143365/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 12 guest-start fail REGR. vs. 142915
On 30.10.2019 23:21, Sander Eikelenboom wrote:
> Call trace seems to be the same in all cases.
>
> --
> Sander
>
>
> (XEN) [2019-10-30 22:07:05.748] AMD-Vi: update_paging_mode Try to access
> pdev_list without aquiring pcidevs_lock.
> (XEN) [2019-10-30 22:07:05.748] [ Xen-4.13.0-rc x86_64
On 31/10/2019 10:18, Jan Beulich wrote:
> On 31.10.2019 09:35, Sander Eikelenboom wrote:
>> Platform is perhaps what specific (older AMD 890FX chipset) and I need the
>> bios workaround:
>> ivrs_ioapic[6]=00:14.0 iommu=on.
>
> Shouldn't matter here.
>
>> On the other hand, this has ran like
On 31.10.2019 09:35, Sander Eikelenboom wrote:
> Platform is perhaps what specific (older AMD 890FX chipset) and I need the
> bios workaround:
> ivrs_ioapic[6]=00:14.0 iommu=on.
Shouldn't matter here.
> On the other hand, this has ran like this for quite some time.
>
> I have 3 guests (HVM)
On 31.10.2019 03:48, Zhang, JinwenX wrote:
> Bug detailed description:
>
> Can not boot up xen with new Domain0 kernel(linux5.4.0-rc3)
>
> Environment :
>
> HW: Cascade Lake server
> Xen: XEN 4.13.0rc1
> Dom0: Linux 5.4.0-rc3
>
> Reproduce steps:
>
On 30.10.2019 19:01, Joe Jin wrote:
> On 10/30/19 10:23 AM, Roger Pau Monné wrote:
>> On Wed, Oct 30, 2019 at 09:38:16AM -0700, Joe Jin wrote:
>>> On 10/30/19 1:24 AM, Roger Pau Monné wrote:
Can you try to add the following debug patch on top of the existing
one and report the output
On 30.10.2019 19:24, Bell, Oren wrote:
> Running Xen Dom0-less leaves the NIC intact, so you're correct in assessing
> that Xen by itself is not the cause.
> As for running without the driver, I'm not sure that's possible (at least for
> my competency). It uses the Intel Base Gigabit driver
On 30.10.2019 23:21, Sander Eikelenboom wrote:
> Call trace seems to be the same in all cases.
Thanks much.
> (XEN) [2019-10-30 22:07:05.748] AMD-Vi: update_paging_mode Try to access
> pdev_list without aquiring pcidevs_lock.
> (XEN) [2019-10-30 22:07:05.748] [ Xen-4.13.0-rc x86_64
61 matches
Mail list logo
