On 21.09.2021 19:51, Andrew Cooper wrote:
> On 21/09/2021 07:53, Jan Beulich wrote:
>> On 20.09.2021 19:25, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -5063,8 +5063,9 @@ long do_hvm_op(unsigned long op,
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>
On 21.09.2021 22:08, Andrew Cooper wrote:
> Not a patch, but an RFC idea for one...
>
> It occurred to me that the cycles parameter from __trace_var() and
> friends is pointless, as the cycles bit is encoded in the top bit of the
> event field anyway, and passed in the adjacent parameter.
>
> Dro
flight 165145 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165145/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestorefail REGR. vs. 152332
test-amd64-amd64-do
On 22.09.2021 01:38, Stefano Stabellini wrote:
> On Mon, 20 Sep 2021, Ian Jackson wrote:
>> Jan Beulich writes ("Re: [xen-unstable test] 164996: regressions - FAIL"):
>>> As per
>>>
>>> Sep 15 14:44:55.502598 [ 1613.322585] Mem-Info:
>>> Sep 15 14:44:55.502643 [ 1613.324918] active_anon:5639 inacti
Hello,
First patch on the series is a trivial change to xenconsoled in order to
use xenforeignmemory stable library in order to map the shared console
ring instead of the unstable libxc interface. It's reviewed and ready to
go in.
Patches 2 and 3 allow setting the host wide command line `gnttab`
Introduce a new domain create field so that toolstack can specify the
maximum grant table version usable by the domain. This is plumbed into
xl and settable by the user as max_grant_version.
Previously this was only settable on a per host basis using the
gnttab command line option.
Note the versi
This patch replaces the usage of xc_map_foreign_range with
xenforeignmemory_map from the stable xenforeignmemory library. Note
there are still other uses of libxc functions which prevents removing
the dependency.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Ian Jack
Exploiting the talloc clean up routines to close the Xen interfaces
is cumbersome, specially when atexit can be used to the same effect.
Convert xc and gnttab to use atexit which allows to drop one
indirection from the storing variables. While there also close the
event channel interface.
No func
Failure to map the shared ring and thus establish a xenstore
connection with a domain shouldn't prevent the "@introduceDomain"
watch from firing, likewise with "@releaseDomain".
In order to handle such events properly xenstored should keep track of
the domains even if the shared communication ring
Allow setting max_grant_version to 0 in order to disable grant table
usage by a domain. This prevents allocating the grant-table structure
inside of Xen and requires guards to be added in several functions in
order to prevent dereferencing the structure.
Note that a domain without a grant table co
Introduce a new grant options flags field in domain create and use it
to signal whether transitive grants are allowed on the domain. This is
settable from xl using the transitive_grants option.
Signed-off-by: Roger Pau Monné
---
docs/man/xl.cfg.5.pod.in| 6 ++
docs/man/xl.conf.5.
On 22/09/2021 13:21, Roger Pau Monne wrote:
Hello,
Hi Roger,
First patch on the series is a trivial change to xenconsoled in order to
use xenforeignmemory stable library in order to map the shared console
ring instead of the unstable libxc interface. It's reviewed and ready to
go in.
Patc
> On 21 Sep 2021, at 22:34, Stefano Stabellini wrote:
>
> On Tue, 21 Sep 2021, Luca Fancellu wrote:
>>> On 17 Sep 2021, at 23:33, Stefano Stabellini wrote:
>>> On Fri, 17 Sep 2021, Luca Fancellu wrote:
> On 16 Sep 2021, at 21:16, Stefano Stabellini
> wrote:
>
> On Thu, 16 S
On 21.09.21 23:44, Stefano Stabellini wrote:
> On Tue, 21 Sep 2021, Oleksandr Andrushchenko wrote:
>> On 21.09.21 10:09, Juergen Gross wrote:
>>> On 21.09.21 09:00, Oleksandr Andrushchenko wrote:
On 21.09.21 09:49, Juergen Gross wrote:
> On 21.09.21 08:38, Oleksandr Andrushchenko wrote:
>
Hi Roger,
On 22/09/2021 13:21, Roger Pau Monne wrote:
Failure to map the shared ring and thus establish a xenstore
connection with a domain shouldn't prevent the "@introduceDomain"
watch from firing, likewise with "@releaseDomain".
In order to handle such events properly xenstored should keep t
Hi Roger,
On 22/09/2021 13:21, Roger Pau Monne wrote:
Allow setting max_grant_version to 0 in order to disable grant table
usage by a domain. This prevents allocating the grant-table structure
inside of Xen and requires guards to be added in several functions in
order to prevent dereferencing th
On Tue, Sep 21, 2021 at 12:12:05PM +0200, Jan Beulich wrote:
> On 21.09.2021 10:32, Roger Pau Monné wrote:
> > On Mon, Sep 20, 2021 at 05:27:17PM +0200, Jan Beulich wrote:
> >> On 20.09.2021 12:20, Roger Pau Monné wrote:
> >>> On Mon, Sep 13, 2021 at 08:41:47AM +0200, Jan Beulich wrote:
> ---
> On 22 Sep 2021, at 09:21, Roger Pau Monne wrote:
>
> Introduce a new grant options flags field in domain create and use it
> to signal whether transitive grants are allowed on the domain. This is
> settable from xl using the transitive_grants option.
>
> Signed-off-by: Roger Pau Monné
> ---
On 22/09/2021 08:03, Jan Beulich wrote:
> On 21.09.2021 22:08, Andrew Cooper wrote:
>> Not a patch, but an RFC idea for one...
>>
>> It occurred to me that the cycles parameter from __trace_var() and
>> friends is pointless, as the cycles bit is encoded in the top bit of the
>> event field anyway,
On 22.09.21 11:19, Julien Grall wrote:
Hi Roger,
On 22/09/2021 13:21, Roger Pau Monne wrote:
Allow setting max_grant_version to 0 in order to disable grant table
usage by a domain. This prevents allocating the grant-table structure
inside of Xen and requires guards to be added in several functi
On Wed, Sep 22, 2021 at 01:57:02PM +0500, Julien Grall wrote:
>
>
> On 22/09/2021 13:21, Roger Pau Monne wrote:
> > Hello,
>
> Hi Roger,
>
> > First patch on the series is a trivial change to xenconsoled in order to
> > use xenforeignmemory stable library in order to map the shared console
> >
On 22.09.2021 11:26, Roger Pau Monné wrote:
> On Tue, Sep 21, 2021 at 12:12:05PM +0200, Jan Beulich wrote:
>> On 21.09.2021 10:32, Roger Pau Monné wrote:
>>> On Mon, Sep 20, 2021 at 05:27:17PM +0200, Jan Beulich wrote:
On 20.09.2021 12:20, Roger Pau Monné wrote:
> On Mon, Sep 13, 2021 at 0
On Wed, Sep 22, 2021 at 02:07:44PM +0500, Julien Grall wrote:
> Hi Roger,
>
> On 22/09/2021 13:21, Roger Pau Monne wrote:
> > Failure to map the shared ring and thus establish a xenstore
> > connection with a domain shouldn't prevent the "@introduceDomain"
> > watch from firing, likewise with "@re
On Wed, Sep 22, 2021 at 11:42:30AM +0200, Jan Beulich wrote:
> On 22.09.2021 11:26, Roger Pau Monné wrote:
> > On Tue, Sep 21, 2021 at 12:12:05PM +0200, Jan Beulich wrote:
> >> On 21.09.2021 10:32, Roger Pau Monné wrote:
> >>> On Mon, Sep 20, 2021 at 05:27:17PM +0200, Jan Beulich wrote:
> On 2
flight 165150 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165150/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 4e467d390eaf6736377766adae0166711866fac3
baseline version:
xen 437e
From: Oleksandr Andrushchenko
Xen-pciback driver was designed to be built for x86 only. But it
can also be used by other architectures, e.g. Arm.
Re-structure the driver in a way that it can be built for other
platforms as well.
Signed-off-by: Oleksandr Andrushchenko
Signed-off-by: Anastasiia L
From: Oleksandr Andrushchenko
Currently PCI backend implements multiple functionalities at a time.
To name a few:
1. it is used as a database for assignable PCI devices, e.g. xl
pci-assignable-{add|remove|list} manipulates that list. So, whenever
the toolstack needs to know which PCI device
The three changes here are largely independent, except for a contextual
dependency between 2 and 3. Note that patch 1 will need actually testing,
on Arm.
1: replace kcalloc() by kvcalloc() when allocating empty pages
2: fix error handling in mmap-resource processing
3: drop "pages" parameter from
Osstest has been suffering test failures for a little while from order-4
allocation failures, resulting from alloc_empty_pages() calling
kcalloc(). As there's no need for physically contiguous space here,
switch to kvcalloc().
Signed-off-by: Jan Beulich
---
RFC: I cannot really test this, as allo
xen_pfn_t is the same size as int only on 32-bit builds (and not even
on Arm32). Hence pfns[] can't be used directly to read individual error
values returned from xen_remap_domain_mfn_array(); every other error
indicator would be skipped/ignored on 64-bit.
Fixes: 3ad0876554ca ("xen/privcmd: add IO
The function doesn't use it and all of its callers say in a comment that
their respective arguments are to be non-NULL only in auto-translated
mode. Since xen_remap_domain_mfn_array() isn't supposed to be used by
non-PV, drop the parameter there as well. It was bogusly passed as non-
NULL (PRIV_VMA
Hi Roger,
On 22/09/2021 14:58, Roger Pau Monné wrote:
On Wed, Sep 22, 2021 at 02:07:44PM +0500, Julien Grall wrote:
Hi Roger,
On 22/09/2021 13:21, Roger Pau Monne wrote:
Failure to map the shared ring and thus establish a xenstore
connection with a domain shouldn't prevent the "@introduceDoma
Hi,
On 22/09/2021 14:42, Jan Beulich wrote:
On 22.09.2021 11:26, Roger Pau Monné wrote:
On Tue, Sep 21, 2021 at 12:12:05PM +0200, Jan Beulich wrote:
On 21.09.2021 10:32, Roger Pau Monné wrote:
On Mon, Sep 20, 2021 at 05:27:17PM +0200, Jan Beulich wrote:
On 20.09.2021 12:20, Roger Pau Monné w
The flag xen_have_vcpu_info_placement was needed to support Xen
hypervisors older than version 3.4. Today the Linux kernel requires
at least Xen 4.0 to be able to run, so xen_have_vcpu_info_placement
can be dropped.
This allows to let some functions return void now, as they can never
fail.
Signed
The pvops function for Xen PV guests handling the interrupt flag are
much more complex than needed.
With the supported Xen hypervisor versions they can be simplified a
lot, especially by removing the need for disabling preemption.
Juergen Gross (2):
x86/xen: remove xen_have_vcpu_info_placement
The initial pvops functions handling irq flags will only ever be called
before interrupts are being enabled.
So make the __init and switch them to be dummy functions:
- xen_save_fl() can always return 0
- xen_irq_disable() is a nop
- xen_irq_enable() can BUG()
Add some generic paravirt functions
Hi Christoph:
This patch follows your purposal in the previous discussion.
Could you have a look?
"use vmap_pfn as in the current series. But in that case I think
we should get rid of the other mapping created by vmalloc. I
though a bit about finding a way to apply the offset in
On 21.09.21 09:02, Juergen Gross wrote:
Disabling preemption in xen_irq_enable() is not needed. There is no
risk of missing events due to preemption, as preemption can happen
only in case an event is being received, which is just the opposite
of missing an event.
Signed-off-by: Juergen Gross
On 22.09.2021 12:28, Julien Grall wrote:
> Hi,
>
> On 22/09/2021 14:42, Jan Beulich wrote:
>> On 22.09.2021 11:26, Roger Pau Monné wrote:
>>> On Tue, Sep 21, 2021 at 12:12:05PM +0200, Jan Beulich wrote:
On 21.09.2021 10:32, Roger Pau Monné wrote:
> On Mon, Sep 20, 2021 at 05:27:17PM +0200
Jan Beulich writes ("Re: [xen-unstable test] 164996: regressions - FAIL"):
> On 22.09.2021 01:38, Stefano Stabellini wrote:
> > On Mon, 20 Sep 2021, Ian Jackson wrote:
> >>> Sep 15 14:44:55.598538 [ 1613.419061] DMA32: 2788*4kB (UMEC) 890*8kB
> >>> (UMEC) 497*16kB (UMEC) 36*32kB (UMC) 1*64kB (C) 1
Hello All,
The purpose of this patch series is to add PCI passthrough support to Xen on
Arm. PCI passthrough support on ARM is the collaboration work between EPAM and
ARM. ARM submitted the partial RFC [1][2] last year to get early feedback. We
tried to fix all the comments and added more features
On Arm, the initial plan is to only support GICv3 ITS which doesn't
require us to manage the MSIs because the HW will protect against
spoofing. Move the code under CONFIG_HAS_PCI_MSI flag to gate the code
for ARM.
No functional change intended.
Signed-off-by: Rahul Singh
Reviewed-by: Daniel P. S
Compilation error is observed when HAS_PCI is enabled for ARM
architecture.
Add definition for arch_iommu_use_permitted() and
arch_pci_clean_pirqs().
pci.c: In function ‘deassign_device’:
pci.c:849:49: error: implicit declaration of function ‘pci_to_dev’;
did you mean ‘dt_to_dev’? [-Werror=implic
prelink.o: In function `pcie_aer_get_firmware_first’:
drivers/passthrough/pci.c:1251: undefined reference to `apei_hest_parse'
Compilation error is observed when ACPI and HAS_PCI is enabled for ARM
architecture. APEI not supported on ARM yet move the code under
CONFIG_X86 flag to gate the code for
ARM architecture does not implement I/O ports. Ignore this call on ARM
to avoid the overhead of making a hypercall just for Xen to return
-ENOSYS.
Signed-off-by: Rahul Singh
---
Change in v2:
- Instead of returning success in XEN, ignored the call in xl.
---
tools/libs/ctrl/xc_domain.c | 9 +
Hardware domain is in charge of doing the PCI enumeration and will
discover the PCI devices and then will communicate to XEN via hyper
call PHYSDEVOP_pci_device_add(..) to add the PCI devices in XEN.
Also implement PHYSDEVOP_pci_device_remove(..) to remove the PCI device.
As most of the code for
Based on tag Linux v5.14.2 commit bbdd3de144fc142f2f4b9834c9241cc4e7f3d3fc
Import the Linux helper of_property_read_variable_u32_array. This
function find and read an array of 32 bit integers from a property,
with bounds on the minimum and maximum array size.
Signed-off-by: Rahul Singh
---
Chang
Based on tag Linux v5.14.2 commit bbdd3de144fc142f2f4b9834c9241cc4e7f3d3fc
Import the Linux helper of_property_read_u32_array. This function find
and read an array of 32 bit integers from a property.
Signed-off-by: Rahul Singh
---
Change in v2: Patch introduced in v2
---
xen/include/xen/device_
Based on tag Linux v5.14.2 commit bbdd3de144fc142f2f4b9834c9241cc4e7f3d3fc
Import the Linux helper of_get_pci_domain_nr. This function will try to
obtain the host bridge domain number by finding a property called
"linux,pci-domain" of the given device node.
Signed-off-by: Rahul Singh
---
Change
pci_init(..) will be called during xen startup to initialize and probe
the PCI host-bridge driver.
Signed-off-by: Rahul Singh
---
Change in v2:
- ACPI init function to return int
- pci_segments_init() called before dt/acpi init
---
xen/arch/arm/pci/pci.c | 54 ++
Add cmdline boot option "pci-passthrough = = " to enable
disable the PCI passthrough support on ARM.
Signed-off-by: Rahul Singh
---
Change in v2:
- Add option in xen-command-line.pandoc
- Change pci option to pci-passthrough
- modify option from custom_param to boolean param
---
docs/misc/xen-co
XEN during boot will read the PCI device tree node “reg” property
and will map the PCI config space to the XEN memory.
As of now only "pci-host-ecam-generic" compatible board is supported.
"linux,pci-domain" device tree property assigns a fixed PCI domain
number to a host bridge, otherwise an uns
From: Oleksandr Andrushchenko
Add support for Xilinx ZynqMP PCI host controller to map the PCI config
space to the XEN memory.
Patch helps to understand how the generic infrastructure for PCI
host-bridge discovery will be used for future references.
Signed-off-by: Oleksandr Andrushchenko
---
C
Implement generic pci access functions to read/write the configuration
space.
Signed-off-by: Rahul Singh
---
Change in v2: Fixed comments
---
xen/arch/arm/pci/pci-access.c | 58 ++
xen/arch/arm/pci/pci-host-common.c | 19 ++
xen/include/asm-arm/pci.h
The existing VPCI support available for X86 is adapted for Arm.
When the device is added to XEN via the hyper call
“PHYSDEVOP_pci_device_add”, VPCI handler for the config space
access is added to the Xen to emulate the PCI devices config space.
A MMIO trap handler for the PCI ECAM space is registe
This patch will be reverted once we add support for VPCI MSI/MSIX
support on ARM.
Signed-off-by: Rahul Singh
---
Change in v2: Patch introduced in v2
---
xen/drivers/vpci/Makefile | 3 ++-
xen/drivers/vpci/header.c | 2 ++
xen/include/asm-arm/pci.h | 8
3 files changed, 12 insertions(+)
libxl will create an emulated PCI device tree node in the device tree to
enable the guest OS to discover the virtual PCI during guest boot.
Emulated PCI device tree node will only be created when there is any
device assigned to guest.
A new area has been reserved in the arm guest physical map at
w
If the property is not present in the device tree node for host bridge,
XEN while creating the dtb for hwdom will create this property and
assigns the already allocated segment to the host bridge
so that XEN and linux will have the same segment for the host bridges.
Signed-off-by: Rahul Singh
---
Commit 540a637c3410780b519fc055f432afe271f642f8 defines a new
helper mark_page_free to extract common codes, while it accidently
breaks the local variable "tainted".
This patch fix it by letting mark_page_free() return bool of whether the
page is offlined and rename local variable "tainted" to "pg
Hi Penny,
> On 22 Sep 2021, at 12:44, Penny Zheng wrote:
>
> Commit 540a637c3410780b519fc055f432afe271f642f8 defines a new
> helper mark_page_free to extract common codes, while it accidently
> breaks the local variable "tainted".
>
> This patch fix it by letting mark_page_free() return bool of
flight 165148 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165148/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On Tue, Sep 21, 2021 at 09:16:44AM +0200, Jan Beulich wrote:
> Assuming that the accounting for IOMMU page tables will also take care
> of the P2M needs was wrong: dom0_paging_pages() can determine a far
> higher value, high enough for the system to run out of memory while
> setting up Dom0. Hence
On Mon, 2021-09-13 at 13:44 +0100, Alex Bennée wrote:
> Hi,
>
> As we consider the next cycle for Project Stratos I would like to make
> some more progress on hypervisor agnosticism for our virtio backends.
> While we have implemented a number of virtio vhost-user backends using C
> we've rapidly
flight 165151 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165151/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f334c5a41dc4702b1c767c6614025aa2f802f9a4
baseline version:
ovmf 542cba73d21b7bcc1e385
On 22.09.2021 13:20, Ian Jackson wrote:
> Jan Beulich writes ("Re: [xen-unstable test] 164996: regressions - FAIL"):
>> On 22.09.2021 01:38, Stefano Stabellini wrote:
>>> On Mon, 20 Sep 2021, Ian Jackson wrote:
> Sep 15 14:44:55.598538 [ 1613.419061] DMA32: 2788*4kB (UMEC) 890*8kB
> (UMEC)
Jan Beulich writes ("Re: [xen-unstable test] 164996: regressions - FAIL"):
> Is the Dom0 kernel used here a distro one or our own build of one of
> the upstream trees? In the latter case I'd expect propagation to be
> quite a bit faster than in the former case.
It's our own build.
> > But I'm lo
On 22.09.21 12:23, Julien Grall wrote:
Hi Roger,
On 22/09/2021 14:58, Roger Pau Monné wrote:
On Wed, Sep 22, 2021 at 02:07:44PM +0500, Julien Grall wrote:
Hi Roger,
On 22/09/2021 13:21, Roger Pau Monne wrote:
Failure to map the shared ring and thus establish a xenstore
connection with a doma
On Wed, Sep 22, 2021 at 12:31:00PM +0200, Juergen Gross wrote:
> The pvops function for Xen PV guests handling the interrupt flag are
> much more complex than needed.
>
> With the supported Xen hypervisor versions they can be simplified a
> lot, especially by removing the need for disabling preemp
On 22/09/2021 08:01, Jan Beulich wrote:
> On 21.09.2021 19:51, Andrew Cooper wrote:
>> On 21/09/2021 07:53, Jan Beulich wrote:
>>> On 20.09.2021 19:25, Andrew Cooper wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5063,8 +5063,9 @@ long do_hvm_op(unsigned long op
On Tue, Sep 21, 2021 at 09:17:15AM +0200, Jan Beulich wrote:
> Leaving shadow setup just to the L1TF tasklet means running Dom0 on a
> minimally acceptable shadow memory pool, rather than what normally
> would be used (also, for example, for PVH). Populate the pool before
> triggering the tasklet,
On 22.09.2021 14:29, Ian Jackson wrote:
> I'm not sure, though, that I fully understand the design principles
> behind non-order-0 allocations, and memory sizing, and so on. Your
> earlier mail suggeted there may not be a design principle, and that
> anything relying on non-order-0 atomic allocati
On 9/22/21 6:17 AM, Jan Beulich wrote:
> @@ -817,7 +818,7 @@ static long privcmd_ioctl_mmap_resource(
> unsigned int i;
>
> for (i = 0; i < num; i++) {
> - rc = pfns[i];
> + rc = errs[i];
>
On 21/09/2021 08:17, Jan Beulich wrote:
> Leaving shadow setup just to the L1TF tasklet means running Dom0 on a
> minimally acceptable shadow memory pool, rather than what normally
> would be used (also, for example, for PVH). Populate the pool before
> triggering the tasklet, on a best effort basi
On 22.09.2021 14:58, Andrew Cooper wrote:
> On 22/09/2021 08:01, Jan Beulich wrote:
>> On 21.09.2021 19:51, Andrew Cooper wrote:
>>> On 21/09/2021 07:53, Jan Beulich wrote:
On 20.09.2021 19:25, Andrew Cooper wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@
On 22.09.2021 15:29, Boris Ostrovsky wrote:
> On 9/22/21 6:17 AM, Jan Beulich wrote:
>> @@ -817,7 +818,7 @@ static long privcmd_ioctl_mmap_resource(
>> unsigned int i;
>>
>> for (i = 0; i < num; i++) {
>> -rc = pfns[i];
>> +
(+ Some AWS folks)
Hi Juergen,
On 22/09/2021 17:34, Juergen Gross wrote:
On 22.09.21 12:23, Julien Grall wrote:
Hi Roger,
On 22/09/2021 14:58, Roger Pau Monné wrote:
On Wed, Sep 22, 2021 at 02:07:44PM +0500, Julien Grall wrote:
Hi Roger,
On 22/09/2021 13:21, Roger Pau Monne wrote:
Failure
On 22.09.2021 15:31, Andrew Cooper wrote:
> On 21/09/2021 08:17, Jan Beulich wrote:
>> @@ -933,7 +934,18 @@ int __init dom0_construct_pv(struct doma
>> #ifdef CONFIG_SHADOW_PAGING
>> if ( opt_dom0_shadow )
>> {
>> +bool preempted;
>> +
>> printk("Switching dom0 to using
flight 165147 xen-unstable real [real]
flight 165154 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165147/
http://logs.test-lab.xenproject.org/osstest/logs/165154/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On 9/22/21 9:39 AM, Jan Beulich wrote:
> On 22.09.2021 15:29, Boris Ostrovsky wrote:
>> On 9/22/21 6:17 AM, Jan Beulich wrote:
>>> @@ -817,7 +818,7 @@ static long privcmd_ioctl_mmap_resource(
>>> unsigned int i;
>>>
>>> for (i = 0; i < num; i++) {
>>> -
On 9/22/21 6:18 AM, Jan Beulich wrote:
> The function doesn't use it and all of its callers say in a comment that
> their respective arguments are to be non-NULL only in auto-translated
> mode. Since xen_remap_domain_mfn_array() isn't supposed to be used by
> non-PV, drop the parameter there as w
On 22.09.2021 13:48, Bertrand Marquis wrote:
>> On 22 Sep 2021, at 12:44, Penny Zheng wrote:
>>
>> Commit 540a637c3410780b519fc055f432afe271f642f8 defines a new
>> helper mark_page_free to extract common codes, while it accidently
>> breaks the local variable "tainted".
>>
>> This patch fix it by
Introduce the uefi,cfg-load DT property of /chosen
node for ARM whose presence decide whether to force
the load of the UEFI Xen configuration file.
The logic is that if any multiboot,module is found in
the DT, then the uefi,cfg-load property is used to see
if the UEFI Xen configuration file is nee
This serie introduces a way to start a dom0less setup when Xen is booting as EFI
application.
Using the device tree it's now possible to fetch from the disk and load in
memory all the modules needed to start any domU defined in the DT.
Dom0less for now is supported only by the arm architecture.
Lu
This patch introduces the support for dom0less configuration
when using UEFI boot on ARM, it permits the EFI boot to
continue if no dom0 kernel is specified but at least one domU
is found.
Introduce the new property "uefi,binary" for device tree boot
module nodes that are subnode of "xen,domain" c
On Tue, Sep 21, 2021 at 09:17:37AM +0200, Jan Beulich wrote:
> Certain notifications of Dom0 to Xen are independent of the mode Dom0 is
> running in. Permit further PCI related ones (only their modern forms).
> Also include the USB2 debug port operation at this occasion.
>
> Signed-off-by: Jan Beu
On Wed, Sep 22, 2021 at 03:50:25PM +0200, Jan Beulich wrote:
> On 22.09.2021 15:31, Andrew Cooper wrote:
> > On 21/09/2021 08:17, Jan Beulich wrote:
> >> @@ -933,7 +934,18 @@ int __init dom0_construct_pv(struct doma
> >> #ifdef CONFIG_SHADOW_PAGING
> >> if ( opt_dom0_shadow )
> >> {
> >>
On 22.09.2021 16:25, Roger Pau Monné wrote:
> On Wed, Sep 22, 2021 at 03:50:25PM +0200, Jan Beulich wrote:
>> On 22.09.2021 15:31, Andrew Cooper wrote:
>>> On 21/09/2021 08:17, Jan Beulich wrote:
@@ -933,7 +934,18 @@ int __init dom0_construct_pv(struct doma
#ifdef CONFIG_SHADOW_PAGING
>>
Along the pieces that were determined to have security relevance
there are quite a few more fixes / improvements (or so I hope)
which were decided to not become part of the XSA itself.
1: obtain IVHD type to use earlier
2: improve (extended) feature detection
3: check IVMD ranges against host impl
Doing this in amd_iommu_prepare() is too late for it, in particular, to
be used in amd_iommu_detect_one_acpi(), as a subsequent change will want
to do. Moving it immediately ahead of amd_iommu_detect_acpi() is
(luckily) pretty simple, (pretty importantly) without breaking
amd_iommu_prepare()'s logi
First of all the documentation is very clear about ACPI table data
superseding raw register data. Use raw register data only if EFRSup is
clear in the ACPI tables (which may still go too far). Additionally if
this flag is clear, the IVRS type 11H table is reserved and hence may
not be recognized.
When such ranges can't be represented as 1:1 mappings in page tables,
reject them as presumably bogus. Note that when we detect features late
(because of EFRSup being clear in the ACPI tables), it would be quite a
bit of work to check for (and drop) out of range IVMD ranges, so IOMMU
initialization
IVHD entries may specify that ATS is to be blocked for a device or range
of devices. Honor firmware telling us so.
While adding respective checks I noticed that the 2nd conditional in
amd_iommu_setup_domain_device() failed to check the IOMMU's capability.
Add the missing part of the condition ther
Disabling should be done in the opposite order of enabling: ATS wants to
be turned off before adjusting the DTE, just like it gets enabled only
after the DTE was suitably prepared. Note that we want ATS to be
disabled as soon as any of the DTEs involved in the handling of a device
(including phanto
Making these dependent upon "iommu=debug" isn't really helpful in the
field. Where touching respective code anyway also make use of %pp and
%pd.
Requested-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
While I'm adding AMD_IOMMU_VERBOSE(), there aren't any uses for now.
It's not really clear t
On 21.09.2021 12:49, Ian Jackson wrote:
> Roger Pau Monné writes ("Re: [PATCH] common: guest_physmap_add_page()'s
> return value needs checking"):
>> On Tue, Sep 21, 2021 at 12:28:12PM +0200, Jan Beulich wrote:
>>> On 21.09.2021 11:20, Roger Pau Monné wrote:
On Wed, Sep 01, 2021 at 06:06:37PM
On Wed, Sep 22, 2021, Paolo Bonzini wrote:
> On 22/09/21 02:05, Sean Christopherson wrote:
> > @@ -1273,6 +1274,11 @@ static inline unsigned int
> > perf_guest_handle_intel_pt_intr(void)
> > }
> > extern void perf_register_guest_info_callbacks(struct
> > perf_guest_info_callbacks *cbs);
> >
On Tue, Sep 21, 2021 at 09:18:05AM +0200, Jan Beulich wrote:
> Like PV Dom0 in order to use the console if in a mode other than text
> 80x25 the kernel needs to be provided information about this mode. Bump
> HVM start info's "current" version to 2 and use a previously reserved
> 32-bit field to pr
On Tue, Sep 21, 2021 at 09:19:06AM +0200, Jan Beulich wrote:
> vcpu_show_registers() didn't do anything for HVM so far. Note though
> that some extra hackery is needed for VMX - see the code comment.
>
> Note further that the show_guest_stack() invocation is left alone here:
> While strictly speak
flight 165149 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165149/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 17 guest-saverestorefail REGR. vs. 152332
test-amd64-coresche
On 22/09/2021 16:01, Roger Pau Monné wrote:
> On Tue, Sep 21, 2021 at 09:18:05AM +0200, Jan Beulich wrote:
>> --- a/xen/include/public/arch-x86/hvm/start_info.h
>> +++ b/xen/include/public/arch-x86/hvm/start_info.h
>> @@ -33,7 +33,7 @@
>> *| magic | Contains the magic value XEN_HVM_S
1 - 100 of 174 matches
Mail list logo
