On 27.09.2021 22:25, Tim Deegan wrote:
> At 13:31 +0200 on 24 Sep (1632490304), Jan Beulich wrote:
>> The 2M logic also first checks _PAGE_PRESENT (and _PAGE_PSE), while
>> the 4k logic appears to infer that the old page was present from
>> p2m_is_{valid,grant}().
>
> I think the p2m_type check
Yes there are other ways but without serial is going to be difficult
because you are not going to see anything until everything works.
How do you boot Xen and Dom0 exactly from EDK2? Are you using GRUB or
loading Xen directly from the EDK2 prompt? Please provide as many
details as possible so
To make the series a bit easier to manage, given that they were fully
acked, I committed patches #1, #2, #6, #7, #8 from the series.
On Tue, 28 Sep 2021, Rahul Singh wrote:
> Hello All,
>
> The purpose of this patch series is to add PCI passthrough support to Xen on
> Arm. PCI passthrough
On Thu, 30 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> vPCI may map and unmap PCI device memory (BARs) being passed through which
> may take a lot of time. For this those operations may be deferred to be
> performed later, so that they can be safely preempted.
>
On Thu, 30 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> PCI host bridges are special devices in terms of implementing PCI
> passthrough. According to [1] the current implementation depends on
> Domain-0 to perform the initialization of the relevant PCI host
>
On Thu, 30 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> In order for vPCI to work it needs to maintain guest and hardware
> domain's views of the configuration space. For example, BARs and
> COMMAND registers require emulation for guests and the guest view
> of
On Thu, 30 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Arm's PCI passthrough implementation doesn't support legacy interrupts,
> but MSI/MSI-X. This can be the case for other platforms too.
> For that reason introduce a new CONFIG_PCI_SUPP_LEGACY_IRQ and add
> it
On Thu, 30 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> The PCI device remove path may now be used by PVH on ARM, so the
> assert is no longer valid.
>
> Signed-off-by: Oleksandr Andrushchenko
> Cc: Ian Jackson
> Cc: Juergen Gross
Acked-by: Stefano Stabellini
On Thu, 30 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> While adding a PCI device mark it as such, so other frameworks
> can distinguish it from DT devices.
> For that introduce an architecture defined helper which may perform
> additional initialization of the
On Thu, 30 Sep 2021, Stefano Stabellini wrote:
> On Thu, 30 Sep 2021, Oleksandr Andrushchenko wrote:
> > From: Oleksandr Andrushchenko
> >
> > Get host bridge node given a PCI device attached to it.
> >
> > This helper will be re-used for adding PCI devices by the subsequent
> > patches.
> >
>
On Thu, 30 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Get host bridge node given a PCI device attached to it.
>
> This helper will be re-used for adding PCI devices by the subsequent
> patches.
>
> Signed-off-by: Oleksandr Andrushchenko
> Signed-off-by:
On Thu, 30 Sep 2021, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add new device type (DEV_PCI) to distinguish PCI devices from platform
> DT devices, so some drivers, like IOMMU, can handle PCI devices
> differently.
>
> Also add a helper which is when given a struct
On Thu, 30 Sep 2021, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> We need to pass info about maximum supported guest address
> space size to the toolstack on Arm in order to properly
> calculate the base and size of the extended region (safe range)
> for the guest. The extended
On Thu, 30 Sep 2021, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> The extended region (safe range) is a region of guest physical
> address space which is unused and could be safely used to create
> grant/foreign mappings instead of wasting real RAM pages from
> the domain memory
On Thu, Sep 30, 2021 at 02:20:33PM -0700, Linus Torvalds wrote:
> On Thu, Sep 30, 2021 at 11:50 AM Mike Rapoport wrote:
> >
> > The first patch is a cleanup of numa_distance allocation in arch_numa I've
> > spotted during the conversion.
> > The second patch is a fix for Xen memory freeing on
On Thu, 30 Sep 2021, Luca Fancellu wrote:
> Add support to load Dom0 boot modules from
> the device tree using the xen,uefi-binary property.
>
> Update documentation about that.
>
> Signed-off-by: Luca Fancellu
> ---
> Changes in v4:
> - Add check to avoid double definition of Dom0 ramdisk
>
On Thu, 30 Sep 2021, Luca Fancellu wrote:
> 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 "xen,uefi-binary" for
On Thu, Sep 30, 2021 at 11:50 AM Mike Rapoport wrote:
>
> The first patch is a cleanup of numa_distance allocation in arch_numa I've
> spotted during the conversion.
> The second patch is a fix for Xen memory freeing on some of the error
> paths.
Well, at least patch 2 looks like something that
From: Mike Rapoport
Since memblock_free() operates on a physical range, make its name reflect
it and rename it to memblock_phys_free(), so it will be a logical
counterpart to memblock_phys_alloc().
The callers are updated with the below semantic patch:
@@
expression addr;
expression size;
@@
-
From: Mike Rapoport
memblock_free_late() is a NOP wrapper for __memblock_free_late(), there is
no point to keep this indirection.
Drop the wrapper and rename __memblock_free_late() to memblock_free_late().
Signed-off-by: Mike Rapoport
---
include/linux/memblock.h | 7 +--
mm/memblock.c
From: Mike Rapoport
Rename memblock_free_ptr() to memblock_free() and use memblock_free()
when freeing a virtual pointer so that memblock_free() will be a
counterpart of memblock_alloc()
The callers are updated with the below semantic patch and manual addition
of (void *) casting to pointers
From: Mike Rapoport
memblock_free_early_nid() is unused and memblock_free_early() is an alias
for memblock_free().
Replace calls to memblock_free_early() with calls to memblock_free() and
remove memblock_free_early() and memblock_free_early_nid().
Signed-off-by: Mike Rapoport
---
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
Reviewed-by: Juergen Gross
---
arch/x86/xen/p2m.c | 2
From: Mike Rapoport
Memory allocation of numa_distance uses memblock_phys_alloc_range() without
actual range limits, converts the returned physical address to virtual and
then only uses the virtual address for further initialization.
Simplify this by replacing memblock_phys_alloc_range() with
From: Mike Rapoport
Hi,
Following the discussion on [1] this is the fix for memblock freeing APIs
mismatch.
The first patch is a cleanup of numa_distance allocation in arch_numa I've
spotted during the conversion.
The second patch is a fix for Xen memory freeing on some of the error
paths.
I
flight 165329 linux-5.4 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/165329/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 14 guest-start fail REGR. vs. 165206
flight 165330 ovmf running [real]
http://logs.test-lab.xenproject.org/osstest/logs/165330/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 3 hosts-allocate running
flight 165333 linux-linus running [real]
http://logs.test-lab.xenproject.org/osstest/logs/165333/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt queued
flight 165331 qemu-mainline running [real]
http://logs.test-lab.xenproject.org/osstest/logs/165331/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat fail REGR. vs. 164950
flight 165334 xtf running [real]
http://logs.test-lab.xenproject.org/osstest/logs/165334/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-13 hosts-allocate running
We have staff on site and are going to replace some PDUs. There will
be some incomplete flight reports and then an outage. I'm not sure
when service will be restored...
Ian.
On 30/09/2021 17:17, Anthony PERARD wrote:
> From: Anthony PERARD
>
> We can add qemu into the container so that there's no need to install
> it everytime we run a test.
>
> Signed-off-by: Anthony PERARD
> ---
>
> Also, smoke tests stopped working as of today due to outdated
> root certificate,
[snip]
>> +bool found = false;
>> +
>> +pcidevs_lock();
>> +list_for_each_entry ( vdev, >vdev_list, list )
>> +{
>> +if ( vdev->sbdf.sbdf == sbdf->sbdf )
>> +{
>> +/* Replace virtual SBDF with the physical one. */
>> +*sbdf =
On Thu, Sep 30, 2021 at 05:20:31PM +0100, Andrew Cooper wrote:
> On 30/09/2021 17:17, Anthony PERARD wrote:
> > From: Anthony PERARD
> >
> > Xen is now built without CONFIG_PV32 by default and thus test jobs
> > "qemu-smoke-x86-64-gcc" and "qemu-smoke-x86-64-clang" fails because
> > they are
On 30/09/2021 17:17, Anthony PERARD wrote:
> From: Anthony PERARD
>
> Xen is now built without CONFIG_PV32 by default and thus test jobs
> "qemu-smoke-x86-64-gcc" and "qemu-smoke-x86-64-clang" fails because
> they are using XTF's "test-pv32pae-example" which is an hello word
> 32bit PV guest.
>
>
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.gitlab-pv32-test-fix-v1
Fixing tests due to CONFIG_PV32 missing.
debian:stretch container needs updating due to certificate issue, so also
install qemu in the container.
Anthony
From: Anthony PERARD
Xen is now built without CONFIG_PV32 by default and thus test jobs
"qemu-smoke-x86-64-gcc" and "qemu-smoke-x86-64-clang" fails because
they are using XTF's "test-pv32pae-example" which is an hello word
32bit PV guest.
As we are looking for whether Xen boot or not with a
From: Anthony PERARD
We can add qemu into the container so that there's no need to install
it everytime we run a test.
Signed-off-by: Anthony PERARD
---
Also, smoke tests stopped working as of today due to outdated
root certificate, so container needs to be updated anyway.
fatal: unable
> On 29 Sep 2021, at 08:46, Juergen Gross wrote:
>
> The interface definition of PV USB devices is lacking the specification
> of possible values of the status field in a response. Those are
> negative errno values as used in Linux, so they might differ in other
> OS's. Specify them via
> On 29 Sep 2021, at 08:46, Juergen Gross wrote:
>
> The PV USB protocol is poorly described. Add a more detailed
> description to the usbif.h header file.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Luca Fancellu
> ---
> xen/include/public/io/usbif.h | 164
[adhoc adhoc]
harness 3a3089c9: mfi-common: Drop Linux dom0 i386 tests for newer Lin...
165337: all pass
flight 165337 xen-unstable adhoc [adhoc]
http://logs.test-lab.xenproject.org/osstest/logs/165337/
Perfect :-)
All tests in this flight passed as required
jobs:
build-arm64-pvops
> On 29 Sep 2021, at 23:52, Oleksandr Tyshchenko wrote:
>
> From: Oleksandr Tyshchenko
>
> The extended region (safe range) is a region of guest physical
> address space which is unused and could be safely used to create
> grant/foreign mappings instead of wasting real RAM pages from
> the
On 28.09.2021 20:18, Rahul Singh wrote:
> 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.
>
>
On 28.09.2021 20:18, Rahul Singh wrote:
> @@ -62,8 +63,21 @@ static int __init acpi_pci_init(void)
> }
> #endif
>
> +/*
> + * By default pci passthrough is disabled
> + */
Nit: This is a single line comment.
> +bool __read_mostly pci_passthrough_enabled = false;
Nit: Unnecessary
On 28.09.2021 20:18, Rahul Singh wrote:
> 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(..)
Hi Luca,
> On 30 Sep 2021, at 15:28, Luca Fancellu wrote:
>
> Introduce the xen,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
Hi Luca,
> On 30 Sep 2021, at 15:28, Luca Fancellu wrote:
>
> Add support to load Dom0 boot modules from
> the device tree using the xen,uefi-binary property.
>
> Update documentation about that.
>
> Signed-off-by: Luca Fancellu
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
>
Hi Luca,
> On 30 Sep 2021, at 15:28, Luca Fancellu wrote:
>
> 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
Add support to load Dom0 boot modules from
the device tree using the xen,uefi-binary property.
Update documentation about that.
Signed-off-by: Luca Fancellu
---
Changes in v4:
- Add check to avoid double definition of Dom0 ramdisk
from cfg file and DT
- Fix if conditions indentation in boot.c
-
Introduce the xen,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 xen,uefi-cfg-load property is used to see
if the UEFI Xen configuration
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 "xen,uefi-binary" for device tree boot
module nodes that are subnode of
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.
On 29.09.2021 18:56, Stefano Stabellini wrote:
> On Tue, 28 Sep 2021, Rahul Singh wrote:
>> 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
On 29/09/2021 17:44, Andrew Donnellan wrote:
On 29/9/21 11:43 pm, Uwe Kleine-König wrote:> I'm not a huge fan either,
I used it to keep the control flow as is and
without introducing several calls to to_pci_driver.
The whole code looks as follows:
list_for_each_entry(afu_dev,
On 28.09.21 00:00, Luis Chamberlain wrote:
We never checked for errors on device_add_disk() as this function
returned void. Now that this is fixed, use the shiny new error
handling. The function xlvbd_alloc_gendisk() typically does the
unwinding on error on allocating the disk and creating the
On 27.09.2021 16:24, Ian Jackson wrote:
> The mainline development branch of Xen is has taken the first step
> towards stabilisation for 4.16: new features not yet submitted, at
> least in draft form, will now be deferred to the following release.
>
> We aim to make each Xen release as good as
On 28.09.21 09:35, Oleksandr Andrushchenko wrote:
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.
Currently PCI backend implements multiple functionalities at a time,
such as:
1. It is used as a
On 30.09.21 14:21, Jan Beulich wrote:
Both xen_pvh and xen_start_flags get written just once early during
init. Using the respective annotation then allows the open-coded placing
in .data to go away.
Additionally the former, like the latter, wants exporting, or else
xen_pvh_domain() can't be
On 30.09.21 14:19, Jan Beulich wrote:
This was effectively lost while dropping PVHv1 code. Move the function
and arrange for it to be called the same way as done in PV mode. Clearly
this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
check that was recently removed, as that's a
When moving away RAM pages, there having been a mapping of those is not
a proper indication that instead MMIO should be mapped there. At the
point in time this effectively covers the low megabyte only. Mapping of
that is, however, the job of init_mem_mapping(). Comparing the two one
can also spot
Considerations for it are a leftover from when 32-bit was still
supported.
Signed-off-by: Jan Beulich
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -306,10 +306,6 @@ static void __init xen_update_mem_tables
BUG();
}
- /* Update kernel mapping, but not
Marking the page tableas pinned without ever actually pinning is was
probably an oversight in the first place. The main reason for the change
is more subtle, though: The write of the one present entry each here and
in the subsequently allocated L2 table engage a code path in the
hypervisor which
Using __native_set_fixmap() here means guaranteed trap-and-emulate
instances the hypervisor has to deal with. Since the virtual address
covered by the to be adjusted page table entry is easy to determine (and
actually already gets obtained in a special case), simply use an
available, easy to
Commit f7c90c2aa400 ("x86/xen: don't write ptes directly in 32-bit PV
guests") needlessly (and heavily) penalized 64-bit guests here: The
majority of the early page table updates is to writable pages (which get
converted to r/o only after all the writes are done), in particular
those involved in
In preparation for restoring xen_set_pte_init()'s original behavior of
avoiding hypercalls, make set_pte_mfn() no longer use the standard
set_pte() code path. That one is more complicated than the alternative
of simply using an available hypercall directly. This way we can avoid
introducing a fair
The observed (by the human eye) performance difference of early boot
between native and PV-on-Xen was just too large to not look into. As
it turns out, gaining performance back wasn't all that difficult.
While the series (re)introduces a small number of PTWR emulations on
the boot path (from
Both xen_pvh and xen_start_flags get written just once early during
init. Using the respective annotation then allows the open-coded placing
in .data to go away.
Additionally the former, like the latter, wants exporting, or else
xen_pvh_domain() can't be used from modules.
Signed-off-by: Jan
Two of the variables can live in .init.data, allowing the open-coded
placing in .data to go away. Another "variable" is used to communicate a
size value only to very early assembly code, which hence can be both
const and live in .init.*. Additionally two functions were lacking
__init annotations.
This was effectively lost while dropping PVHv1 code. Move the function
and arrange for it to be called the same way as done in PV mode. Clearly
this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
check that was recently removed, as that's a PV-only feature.
Since the string
Without announcing hvc0 as preferred it won't get used as long as tty0
gets registered earlier. This is particularly problematic with there not
being any screen output for PVH Dom0 when the screen is in graphics
mode, as the necessary information doesn't get conveyed yet from the
hypervisor.
xenboot_write_console() is dealing with these quite fine so I don't see
why xenboot_console_setup() would return -ENOENT in this case.
Adjust documentation accordingly.
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
--- a/Documentation/admin-guide/kernel-parameters.txt
+++
With preferred consoles "tty" and "hvc" announced as preferred,
registering "xenboot" early won't result in use of the console: It also
needs to be registered as preferred. Generalize this from being DomU-
only so far.
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
---
v2: Re-base.
---
The xen_hvm_early_write() path better wouldn't be taken in this case;
while port 0xE9 can be used, the hypercall path is quite a bit more
efficient. Put that first, as it may also work for DomU-s (see also
xen_raw_console_write()).
While there also bail from the function when the first
Decouple XEN_DOM0 from XEN_PV, converting some existing uses of XEN_DOM0
to a new XEN_PV_DOM0. (I'm not convinced all are really / should really
be PV-specific, but for starters I've tried to be conservative.)
For PVH Dom0 the hypervisor populates MADT with only x2APIC entries, so
without x2APIC
Like xen_start_flags, xen_domain_type gets set before .bss gets cleared.
Hence this variable also needs to be prevented from getting put in .bss,
which is possible because XEN_NATIVE is an enumerator evaluating to
zero. Any use prior to init_hvm_pv_info() setting the variable again
would lead to
In order to try to debug hypervisor side breakage from XSA-378 I found
myself urged to finally give PVH Dom0 a try. Sadly things didn't work
quite as expected. In the course of investigating these issues I actually
spotted one piece of PV Dom0 breakage as well, a fix for which is also
included
Hi Andrew,
On 30.09.2021 12:40, Andrew Cooper wrote:
> On 30/09/2021 10:26, Michal Orzel wrote:
>> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
>> index 4b1e3028d2..4a75203b9f 100644
>> --- a/docs/man/xl.cfg.5.pod.in
>> +++ b/docs/man/xl.cfg.5.pod.in
>> @@ -2843,6 +2843,18 @@
Hi Jan
> On 30 Sep 2021, at 8:48 am, Jan Beulich wrote:
>
> On 29.09.2021 18:41, Stefano Stabellini wrote:
>> On Tue, 28 Sep 2021, Rahul Singh wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/arm/pci/pci-host-zynqmp.c
>>> @@ -0,0 +1,63 @@
>>> +/*
>>> + * Based on Linux
On 30/09/2021 10:26, Michal Orzel wrote:
> diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
> index 4b1e3028d2..4a75203b9f 100644
> --- a/docs/man/xl.cfg.5.pod.in
> +++ b/docs/man/xl.cfg.5.pod.in
> @@ -2843,6 +2843,18 @@ Currently, only the "sbsa_uart" model is supported for
>
On Tue, Sep 14, 2021 at 01:30:27PM +, P J P wrote:
> Hello Philippe, all
>
> >On Thursday, 9 September, 2021, 03:58:40 pm IST, Daniel P. Berrangé
> > wrote:
> >On Thu, Sep 09, 2021 at 01:20:14AM +0200, Philippe Mathieu-Daudé wrote:
> >> This series is experimental! The goal is to better
On 30.09.21 13:14, Jan Beulich wrote:
> On 30.09.2021 11:21, Oleksandr Andrushchenko wrote:
>> On 30.09.21 12:06, Jan Beulich wrote:
>>> On 30.09.2021 10:45, Oleksandr Andrushchenko wrote:
On 30.09.21 11:21, Jan Beulich wrote:
> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote:
>>
On 30.09.21 13:23, Jan Beulich wrote:
> On 30.09.2021 11:34, Oleksandr Andrushchenko wrote:
>> On 30.09.21 11:51, Jan Beulich wrote:
>>> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote:
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -831,6 +831,66 @@
flight 165320 linux-linus real [real]
flight 165332 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165320/
http://logs.test-lab.xenproject.org/osstest/logs/165332/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 30.09.2021 11:35, Oleksandr Andrushchenko wrote:
> On 30.09.21 11:53, Jan Beulich wrote:
>> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote:
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -889,6 +889,31 @@ int pci_remove_virtual_device(struct domain
On 30.09.2021 11:34, Oleksandr Andrushchenko wrote:
> On 30.09.21 11:51, Jan Beulich wrote:
>> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote:
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -831,6 +831,66 @@ int pci_remove_device(u16 seg, u8 bus, u8
On 30.09.2021 11:21, Oleksandr Andrushchenko wrote:
> On 30.09.21 12:06, Jan Beulich wrote:
>> On 30.09.2021 10:45, Oleksandr Andrushchenko wrote:
>>> On 30.09.21 11:21, Jan Beulich wrote:
On 30.09.2021 09:52, Oleksandr Andrushchenko wrote:
> @@ -1429,6 +1433,11 @@ static int
On 30.09.2021 11:26, Michal Orzel wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -483,7 +483,7 @@ static int sanitise_domain_config(struct
> xen_domctl_createdomain *config)
> ~(XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap |
> XEN_DOMCTL_CDF_s3_integrity |
Hello,
the issue pointed out in [1] (and hence the proposed fix in a reply) is
actually pointing out a bigger problem, addressing of which may also
invalidate that proposed fix.
First, fundamentally any code path reaching p2m_pt_set_entry() (i.e. in
particular any caller of p2m_set_entry()) is
Hi Michal,
> On 30 Sep 2021, at 10:26, Michal Orzel wrote:
>
> Add parameter vpmu to xl domain configuration syntax
> to enable the access to PMU registers by disabling
> the PMU traps.
>
> This change does not expose the full PMU to the guest.
> Long term, we will want to at least expose the
flight 165325 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165325/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 30.09.21 11:53, Jan Beulich wrote:
> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote:
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -889,6 +889,31 @@ int pci_remove_virtual_device(struct domain *d, const
>> struct pci_dev *pdev)
>> xfree(vdev);
On 30.09.21 11:51, Jan Beulich wrote:
> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> Assign SBDF to the PCI devices being passed through with bus 0.
> This reads a little odd: If bus is already known (and I think you imply
> segment to also be
Add parameter vpmu to xl domain configuration syntax
to enable the access to PMU registers by disabling
the PMU traps.
This change does not expose the full PMU to the guest.
Long term, we will want to at least expose the PMU
interrupts, device-tree binding. For more use cases
we will also need to
On 30.09.21 12:06, Jan Beulich wrote:
> On 30.09.2021 10:45, Oleksandr Andrushchenko wrote:
>> On 30.09.21 11:21, Jan Beulich wrote:
>>> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote:
@@ -1429,6 +1433,11 @@ static int assign_device(struct domain *d, u16 seg,
u8 bus, u8 devfn, u32
flight 165319 qemu-mainline real [real]
flight 165328 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/165319/
http://logs.test-lab.xenproject.org/osstest/logs/165328/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On 30.09.2021 10:45, Oleksandr Andrushchenko wrote:
> On 30.09.21 11:21, Jan Beulich wrote:
>> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote:
>>> @@ -1429,6 +1433,11 @@ static int assign_device(struct domain *d, u16 seg,
>>> u8 bus, u8 devfn, u32 flag)
>>> rc =
On 30.09.2021 09:52, Oleksandr Andrushchenko wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -889,6 +889,31 @@ int pci_remove_virtual_device(struct domain *d, const
> struct pci_dev *pdev)
> xfree(vdev);
> return 0;
> }
> +
> +/*
> + * Find the
On 30.09.2021 09:52, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Assign SBDF to the PCI devices being passed through with bus 0.
This reads a little odd: If bus is already known (and I think you imply
segment to also be known), it's only DF which get assigned.
> The
On 30.09.21 11:21, Jan Beulich wrote:
> On 30.09.2021 09:52, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> When a PCI device gets assigned/de-assigned some work on vPCI side needs
>> to be done for that device. Introduce a pair of hooks so vPCI can handle
>> that.
>>
>>
flight 165321 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/165321/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 442e46d3b6c1931b54111c92e0efb5a797bc622b
baseline version:
ovmf
1 - 100 of 133 matches
Mail list logo
