flight 186030 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186030/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-credit2 8 xen-boot fail in 186023 pass in 186030
On Fri, May 17, 2024 at 05:40:52PM -0700, Stefano Stabellini wrote:
> On Thu, 16 May 2024, Marek Marczykowski-Górecki wrote:
> > Add minimal linux-stubdom smoke test. It starts a simple HVM with
> > linux-stubdom. The actual stubdom implementation is taken from Qubes OS
> > and then stripped off
> -ap2m = array_access_nospec(d->arch.altp2m_p2m, altp2m_idx);
> +ap2m = d->arch.altp2m_p2m[altp2m_idx];
Why is it no longer necessary to use array_access_nospec?
Tamas
On Fri, May 17, 2024 at 9:55 AM Oleksii Kurochko
wrote:
>
> Signed-off-by: Oleksii Kurochko
Acked-by: Tamas K Lengyel
On Fri, May 17, 2024 at 9:55 AM Oleksii Kurochko
wrote:
>
> Signed-off-by: Oleksii Kurochko
Acked-by: Tamas K Lengyel
> Currently altp2m support provided for VT-d only, so option is dependant on
> VMX.
No clue what is meant by "support provided for VT-d only". Altp2m has
nothing to do with VT-d. It would be more accurate to say it's only
implemented for Intel EPT.
Tamas
On Thu, 16 May 2024, Marek Marczykowski-Górecki wrote:
> Based on the initial stubdomain test and existing PCI passthrough tests,
> add one that combines both.
> Schedule it on the AMD runner, as it has less tests right now.
>
> Signed-off-by: Marek Marczykowski-Górecki
With the caveat that if
On Thu, 16 May 2024, Marek Marczykowski-Górecki wrote:
> Add minimal linux-stubdom smoke test. It starts a simple HVM with
> linux-stubdom. The actual stubdom implementation is taken from Qubes OS
> and then stripped off Qubes-specific code. In particular, the remaining
> code does _not_ support:
flight 186028 linux-6.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186028/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185901
test-amd64-amd64-xl-qemuu-win7-amd64
On Thu, 16 May 2024, Marek Marczykowski-Górecki wrote:
> Alpine 3.19 is needed for upcoming stubdomain tests, as linux stubdomain
> build requires dracut-core package (dracut-install tool specifically)
> which isn't available in 3.18. While technically it will be needed only
> in the x86_64
On Thu, 16 May 2024, Marek Marczykowski-Górecki wrote:
> Update 6.1.x kernel to the latest version in this branch. This is
> especially needed to include MSI-X related fixes for stubdomain
> ("xen-pciback: Consider INTx disabled when MSI/MSI-X is enabled").
>
> Signed-off-by: Marek
On Thu, 16 May 2024, Marek Marczykowski-Górecki wrote:
> And start collecting qemu log earlier, so it isn't lost in case of a
> timeout during domain startup.
>
> Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Stefano Stabellini
> ---
> automation/scripts/qemu-alpine-x86_64.sh| 2
On Thu, 16 May 2024, Marek Marczykowski-Górecki wrote:
> It fails on larger initramfs (~250MB one), let Linux do it.
>
> Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Stefano Stabellini
> ---
> automation/scripts/qubes-x86-64.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On Thu, 16 May 2024, Marek Marczykowski-Górecki wrote:
> Fedora 29 is long EOL
>
> Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Stefano Stabellini
> ---
> automation/build/fedora/29.dockerfile | 46 +
> automation/build/fedora/39.dockerfile | 46
On Thu, 16 May 2024, Marek Marczykowski-Górecki wrote:
> Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Stefano Stabellini
> ---
> automation/scripts/qubes-x86-64.sh | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/automation/scripts/qubes-x86-64.sh
>
On Fri, 17 May 2024, Nicola Vetrini wrote:
> This rule has no more violations in the codebase, so it can be
> set as clean.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
> ---
> automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
> 1 file
On Fri, 17 May 2024, Jan Beulich wrote:
> On 17.05.2024 03:21, Stefano Stabellini wrote:
> > On Thu, 16 May 2024, Jan Beulich wrote:
> >> 1) In the discussion George claimed that exposing status information in
> >> an uncontrolled manner is okay. I'm afraid I have to disagree, seeing
> >> how a
flight 186027 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186027/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186021
From: Oleksandr Andrushchenko
At the moment, we always allocate an extra 16 slots for IO handlers
(see MAX_IO_HANDLER). So while adding IO trap handlers for the emulated
MSI-X registers we need to explicitly tell that we have additional IO
handlers, so those are accounted.
Signed-off-by:
From: Oleksandr Andrushchenko
Assign SBDF to the PCI devices being passed through with bus 0.
The resulting topology is where PCIe devices reside on the bus 0 of the
root complex itself (embedded endpoints).
This implementation is limited to 32 devices which are allowed on
a single PCI bus.
From: Oleksandr Andrushchenko
There are three originators for the PCI configuration space access:
1. The domain that owns physical host bridge: MMIO handlers are
there so we can update vPCI register handlers with the values
written by the hardware domain, e.g. physical view of the registers
vs
From: Oleksandr Andrushchenko
Xen and/or Dom0 may have put values in PCI_COMMAND which they expect
to remain unaltered. PCI_COMMAND_SERR bit is a good example: while the
guest's (domU) view of this will want to be zero (for now), the host
having set it to 1 should be preserved, or else we'd
From: Volodymyr Babchuk
Guest can try to read config space using different access sizes: 8,
16, 32, 64 bits. We need to take this into account when we are
returning an error back to MMIO handler, otherwise it is possible to
provide more data than requested: i.e. guest issues LDRB instruction
to
This is next version of vPCI rework. Aim of this series is to prepare
ground for introducing PCI support on ARM platform.
in v15:
- reorder so ("arm/vpci: honor access size when returning an error")
comes first
in v14:
- drop first 9 patches as they were committed
- updated ("vpci/header:
Factor out policy getters/setters from both (CPUID and MSR) policy override
functions. Additionally, use host policy rather than featureset when
preparing the cur policy, saving one hypercall and several lines of
boilerplate.
No functional change intended.
Signed-off-by: Alejandro Vallejo
---
v2:
* Removed xc_cpu_policy from xenguest.h
* Added accessors for xc_cpu_policy so the serialised form can be extracted.
* Modified xen-cpuid to use accessors.
Original cover letter
In the context of creating a domain, we currently issue a lot of hypercalls
redundantly while
The idea is to use xc_cpu_policy_t as a single object containing both the
serialised and deserialised forms of the policy. Note that we need lengths
for the arrays, as the serialised policies may be shorter than the array
capacities.
* Add the serialised lengths to the struct so we can
Hello,
The first two patches have been merged so this version has the remaining
two. Only the first of these two patches has changed since v3.
Summary of changes from v3 to v4:
- Drop merged patches.
- _vif_vlan_setup: Add comment that we delete vid 1 due to it being
automatically added.
-
Add a new directory linux-bridge-vlan with example files showing
how to configure systemd-networkd to support a bridge VLAN
configuration.
Signed-off-by: Leigh Brown
---
docs/misc/linux-bridge-vlan/README | 68 ++
docs/misc/linux-bridge-vlan/br0.netdev | 7 +++
Update add_to_bridge shell function to read the vlan parameter from
xenstore and set the bridge VLAN configuration for the VID.
Add additional helper functions to parse the vlan specification,
which consists of one or more of the following:
a) single VLAN (e.g. 10).
b) contiguous range of VLANs
Use the same check that's used in dump_irqs().
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/msi.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index 19830528b65a..0c97fbb3fc03 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -17,6
flight 186025 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186025/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186011
test-amd64-amd64-libvirt 15
Signed-off-by: Oleksii Kurochko
Reviewed-by: Jan Beulich
---
Changes in V5-V10:
- Nothing changed. Only rebase.
---
Changes in V4:
- drop stubs for irq_actor_none() and irq_actor_none() as common/irq.c is
compiled now.
- drop defintion of max_page in stubs.c as common/page_alloc.c is
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V8-V10:
- Nothing changed only rebase.
---
Changes in V7:
- update argument type of maddr_to_virt() function: unsigned long -> paddr_t
- rename argument of PFN_ORDER(): pfn -> pg.
- add Acked-by: Jan Beulich
---
Changes in
Signed-off-by: Oleksii Kurochko
---
Changes in V5-V10:
- Only rebase was done.
---
Changes in V4:
- New patch.
---
xen/arch/riscv/Makefile | 1 +
xen/arch/riscv/vm_event.c | 19 +++
2 files changed, 20 insertions(+)
create mode 100644 xen/arch/riscv/vm_event.c
diff --git
Initially the patch was introduced by Bobby, who takes the header from
Linux kernel.
The following changes were done on top of Bobby's changes:
- atomic##prefix##_*xchg_*(atomic##prefix##_t *v, c_t n) were updated
to use__*xchg_generic()
- drop casts in write_atomic() as they are unnecessary
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V7-V10:
- Only rebase was done.
---
Changes in V6:
- update the commit in stubs.c around /* ... common/irq.c ... */
- add Acked-by: Jan Beulich
---
Changes in V5:
- drop unrelated changes
-
The header was taken from Linux kernl 6.4.0-rc1.
Addionally, were updated:
* add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic
access.
* replace tabs with spaces
* replace __* variale with *__
* introduce generic version of xchg_* and cmpxchg_*.
* drop
Add minimal requied things to be able to build full Xen.
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V5-V10:
- Nothing changed. Only rebase.
---
Changes in V4:
- BUG() was changed to BUG_ON("unimplemented");
- Change "xen/bug.h" to "xen/lib.h" as BUG_ON is defined in
To avoid the compilation error below, it is needed to update to places
in common/page_alloc.c where flsl() is used as now flsl() returns unsigned int:
./include/xen/kernel.h:18:21: error: comparison of distinct pointer types lacks
a cast [-Werror]
18 | (void) (&_x == &_y);
This patch doesn't represent a strict lower bound for GCC and
GNU Binutils; rather, these versions are specifically employed by
the Xen RISC-V container and are anticipated to undergo continuous
testing. Older GCC and GNU Binutils would work,
but this is not a guarantee.
While it is feasible to
Disables unnecessary configs for two cases:
1. By utilizing EXTRA_FIXED_RANDCONFIG for randconfig builds (GitLab CI jobs).
2. By using tiny64_defconfig for non-randconfig builds.
Only configs which lead to compilation issues were disabled.
Remove lines related to disablement of configs which
Signed-off-by: Oleksii Kurochko
---
Changes in V4-V10:
- Nothing changed. Only rebase.
---
Changes in V3:
- new patch.
---
xen/arch/riscv/include/asm/monitor.h | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 xen/arch/riscv/include/asm/monitor.h
diff --git
Taken from Linux-6.4.0-rc1
Xen's bitops.h consists of several Linux's headers:
* linux/arch/include/asm/bitops.h:
* The following function were removed as they aren't used in Xen:
* test_and_set_bit_lock
* clear_bit_unlock
* __clear_bit_unlock
* The following functions
The definition of __read_mostly should be removed in:
https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b3...@suse.com/
The patch introduces it in arch-specific header to not
block enabling of full Xen build for RISC-V.
Signed-off-by: Oleksii Kurochko
---
- [PATCH] move
This patch series performs all of the additions necessary to drop the
build overrides for RISCV and enable the full Xen build. Except in cases
where compatibile implementations already exist (e.g. atomic.h and
bitops.h), the newly added definitions are simple.
The patch series is based on the
The following generic functions were introduced:
* test_bit
* generic__test_and_set_bit
* generic__test_and_clear_bit
* generic__test_and_change_bit
These functions and macros can be useful for architectures
that don't have corresponding arch-specific instructions.
Also, the patch introduces the
> On 17 May 2024, at 14:33, Roger Pau Monne wrote:
>
> Enabling it using an HVM param is fragile, and complicates the logic when
> deciding whether options that interact with altp2m can also be enabled.
>
> Leave the HVM param value for consumption by the guest, but prevent it from
> being
Iterate over the p2m up to the maximum recorded gfn and remove any foreign
mappings, in order to drop the underlying page references and thus don't keep
extra page references if a domain is destroyed while still having foreign
mappings on it's p2m.
The logic is similar to the one used on Arm.
Such information will be needed in order to remove foreign mappings during
teardown for HVM guests.
Right now the introduced counter is not consumed.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Changes since v1:
- Drop max_gfn accounting.
---
xen/arch/x86/include/asm/p2m.h |
Hello,
The following series attempts to solve a shortcoming of HVM/PVH guests
with the lack of support for foreign mappings. Such lack of support
prevents using PVH based guests as stubdomains for example.
Add support in a way similar to how it's done on Arm, by iterating over
the p2m based on
Enabling it using an HVM param is fragile, and complicates the logic when
deciding whether options that interact with altp2m can also be enabled.
Leave the HVM param value for consumption by the guest, but prevent it from
being set. Enabling is now done using and additional altp2m specific field
On 5/17/24 04:08, Chen, Jiqian wrote:
> On 2024/5/16 21:08, Jan Beulich wrote:
>> On 16.05.2024 11:52, Jiqian Chen wrote:
>>> @@ -67,6 +68,41 @@ ret_t pci_physdev_op(int cmd,
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>> +pcidevs_lock();
>>> +pdev = pci_get_pdev(NULL, sbdf);
>>> +
On 17.05.2024 13:14, Chen, Jiqian wrote:
> On 2024/5/17 18:51, Jan Beulich wrote:
>> On 17.05.2024 12:45, Chen, Jiqian wrote:
>>> On 2024/5/16 22:01, Jan Beulich wrote:
On 16.05.2024 11:52, Jiqian Chen wrote:
> +if ( gsi >= nr_irqs_gsi )
> +{
> +ret =
On 17.05.2024 13:01, Chen, Jiqian wrote:
> On 2024/5/17 18:31, Jan Beulich wrote:
>> On 17.05.2024 12:00, Chen, Jiqian wrote:
>>> On 2024/5/17 17:50, Jan Beulich wrote:
On 17.05.2024 11:28, Chen, Jiqian wrote:
> On 2024/5/17 16:20, Jan Beulich wrote:
>> On 17.05.2024 10:08, Chen,
If no other USB HCDs are selected when compiling a small pure virutal
machine, the Xen HCD driver cannot be built.
Fix it by traversing down host/ if CONFIG_USB_XEN_HCD is selected.
Fixes: 494ed3997d75 ("usb: Introduce Xen pvUSB frontend (xen hcd)")
Cc: sta...@vger.kernel.org # v5.17+
flight 186023 linux-linus real [real]
flight 186029 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186023/
http://logs.test-lab.xenproject.org/osstest/logs/186029/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 2024/5/17 18:51, Jan Beulich wrote:
> On 17.05.2024 12:45, Chen, Jiqian wrote:
>> On 2024/5/16 22:01, Jan Beulich wrote:
>>> On 16.05.2024 11:52, Jiqian Chen wrote:
+if ( gsi >= nr_irqs_gsi )
+{
+ret = -EINVAL;
+break;
+}
On 2024/5/17 18:31, Jan Beulich wrote:
> On 17.05.2024 12:00, Chen, Jiqian wrote:
>> On 2024/5/17 17:50, Jan Beulich wrote:
>>> On 17.05.2024 11:28, Chen, Jiqian wrote:
On 2024/5/17 16:20, Jan Beulich wrote:
> On 17.05.2024 10:08, Chen, Jiqian wrote:
>> On 2024/5/16 21:08, Jan Beulich
On 17.05.2024 12:45, Chen, Jiqian wrote:
> On 2024/5/16 22:01, Jan Beulich wrote:
>> On 16.05.2024 11:52, Jiqian Chen wrote:
>>> +if ( gsi >= nr_irqs_gsi )
>>> +{
>>> +ret = -EINVAL;
>>> +break;
>>> +}
>>> +
>>> +if (
On 2024/5/16 22:01, Jan Beulich wrote:
> On 16.05.2024 11:52, Jiqian Chen wrote:
>> Some type of domain don't have PIRQ, like PVH, when
>> passthrough a device to guest on PVH dom0, callstack
>> pci_add_dm_done->XEN_DOMCTL_irq_permission will failed
>> at domain_pirq_to_irq.
>>
>> So, add a new
Hi Jason,
On 2024-05-17 03:19, Jason Andryuk wrote:
On Thu, May 16, 2024 at 6:56 AM Leigh Brown
wrote:
Update add_to_bridge shell function to read the vlan parameter from
xenstore and set the bridge VLAN configuration for the VID.
Add additional helper functions to parse the vlan
On 17.05.2024 12:00, Chen, Jiqian wrote:
> On 2024/5/17 17:50, Jan Beulich wrote:
>> On 17.05.2024 11:28, Chen, Jiqian wrote:
>>> On 2024/5/17 16:20, Jan Beulich wrote:
On 17.05.2024 10:08, Chen, Jiqian wrote:
> On 2024/5/16 21:08, Jan Beulich wrote:
>> On 16.05.2024 11:52, Jiqian
This rule has no more violations in the codebase, so it can be
set as clean.
No functional change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl
Hi Juergen:
On 2024/5/17 18:03, Jürgen Groß wrote:
> On 17.05.24 11:50, Jan Beulich wrote:
>> On 17.05.2024 11:28, Chen, Jiqian wrote:
>>> On 2024/5/17 16:20, Jan Beulich wrote:
On 17.05.2024 10:08, Chen, Jiqian wrote:
> On 2024/5/16 21:08, Jan Beulich wrote:
>> On 16.05.2024 11:52,
On 17.05.24 11:50, Jan Beulich wrote:
On 17.05.2024 11:28, Chen, Jiqian wrote:
On 2024/5/17 16:20, Jan Beulich wrote:
On 17.05.2024 10:08, Chen, Jiqian wrote:
On 2024/5/16 21:08, Jan Beulich wrote:
On 16.05.2024 11:52, Jiqian Chen wrote:
struct physdev_pci_device {
/* IN */
On 2024/5/17 17:50, Jan Beulich wrote:
> On 17.05.2024 11:28, Chen, Jiqian wrote:
>> On 2024/5/17 16:20, Jan Beulich wrote:
>>> On 17.05.2024 10:08, Chen, Jiqian wrote:
On 2024/5/16 21:08, Jan Beulich wrote:
> On 16.05.2024 11:52, Jiqian Chen wrote:
>> struct physdev_pci_device {
On 17.05.2024 11:06, Oleksii K. wrote:
> On Wed, 2024-05-15 at 11:09 +0200, Jan Beulich wrote:
>> But this then needs carrying through to ...
>>
>>> --- a/xen/arch/arm/include/asm/arm64/bitops.h
>>> +++ b/xen/arch/arm/include/asm/arm64/bitops.h
>>> @@ -22,17 +22,15 @@ static /*__*/always_inline
On 17.05.2024 11:28, Chen, Jiqian wrote:
> On 2024/5/17 16:20, Jan Beulich wrote:
>> On 17.05.2024 10:08, Chen, Jiqian wrote:
>>> On 2024/5/16 21:08, Jan Beulich wrote:
On 16.05.2024 11:52, Jiqian Chen wrote:
> struct physdev_pci_device {
> /* IN */
> uint16_t seg;
On 2024/5/17 16:20, Jan Beulich wrote:
> On 17.05.2024 10:08, Chen, Jiqian wrote:
>> On 2024/5/16 21:08, Jan Beulich wrote:
>>> On 16.05.2024 11:52, Jiqian Chen wrote:
struct physdev_pci_device {
/* IN */
uint16_t seg;
>>>
>>> Is re-using this struct for this new sub-op
On Wed, 2024-05-15 at 11:09 +0200, Jan Beulich wrote:
> But this then needs carrying through to ...
>
> > --- a/xen/arch/arm/include/asm/arm64/bitops.h
> > +++ b/xen/arch/arm/include/asm/arm64/bitops.h
> > @@ -22,17 +22,15 @@ static /*__*/always_inline unsigned long
> > __ffs(unsigned long word)
On 17.05.2024 11:00, Chen, Jiqian wrote:
> On 2024/5/16 21:49, Jan Beulich wrote:
>> On 16.05.2024 11:52, Jiqian Chen wrote:
>>> --- a/xen/arch/x86/hvm/hypercall.c
>>> +++ b/xen/arch/x86/hvm/hypercall.c
>>> @@ -76,6 +76,11 @@ long hvm_physdev_op(int cmd,
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>
On 2024/5/16 21:49, Jan Beulich wrote:
> On 16.05.2024 11:52, Jiqian Chen wrote:
>> --- a/xen/arch/x86/hvm/hypercall.c
>> +++ b/xen/arch/x86/hvm/hypercall.c
>> @@ -76,6 +76,11 @@ long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void)
>> arg)
>> case PHYSDEVOP_unmap_pirq:
>>
On 2024/5/16 21:29, Jan Beulich wrote:
> On 16.05.2024 11:52, Jiqian Chen wrote:
>> If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
>> a passthrough device by using gsi, see
>> xen_pt_realize->xc_physdev_map_pirq and
>> pci_add_dm_done->xc_physdev_map_pirq.
>
> xen_pt_realize() is
On Thu, 2024-05-16 at 12:49 +0200, Jan Beulich wrote:
> > Anyway, I am not sure I understand which approach I should use in
> > this
> > patch. You mentioned that possibly test_and_() can't have a generic
> > form, meaning it won't be a set of arch_test_and_() functions.
> >
> > So, can I rename
On 17.05.2024 10:08, Chen, Jiqian wrote:
> On 2024/5/16 21:08, Jan Beulich wrote:
>> On 16.05.2024 11:52, Jiqian Chen wrote:
>>> struct physdev_pci_device {
>>> /* IN */
>>> uint16_t seg;
>>
>> Is re-using this struct for this new sub-op sufficient? IOW are all
>> possible resets equal,
On 2024/5/16 21:08, Jan Beulich wrote:
> On 16.05.2024 11:52, Jiqian Chen wrote:
>> @@ -67,6 +68,41 @@ ret_t pci_physdev_op(int cmd,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>> break;
>> }
>>
>> +case PHYSDEVOP_pci_device_state_reset: {
>> +struct physdev_pci_device dev;
> On 16 May 2024, at 19:58, Andrew Cooper wrote:
>
> We are about to import code licensed under MIT-0. It's compatible for us to
> use, so identify it as a permitted license.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Anthony PERARD
> CC: Juergen Gross
> CC: George Dunlap
> CC: Jan
> On 16 May 2024, at 19:58, Andrew Cooper wrote:
>
> On advise from the systemd leadership.
>
> v2:
> * Import the free-standing example and use that to retain existing
> functionality.
>
> Andrew Cooper (4):
> LICENSES: Add MIT-0 (MIT No Attribution)
> tools: Import standalone
flight 186024 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186024/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 16.05.2024 19:13, Andrew Cooper wrote:
> On 15/05/2024 4:29 pm, Roger Pau Monne wrote:
>> Print the CPU affinity masks as numeric ranges instead of plain hexadecimal
>> bitfields.
>>
>> Signed-off-by: Roger Pau Monné
>> ---
>> xen/arch/x86/irq.c | 10 +-
>> 1 file changed, 5
On 17.05.2024 03:22, Daniel P. Smith wrote:
> On 5/16/24 02:41, Jan Beulich wrote:
>> On 14.05.2024 11:25, Jan Beulich wrote:
>>> On 03.04.2024 08:16, Jan Beulich wrote:
On 02.04.2024 19:06, Andrew Cooper wrote:
> The commit makes a claim without any kind of justification.
Well,
On 17.05.2024 03:36, Henry Wang wrote:
> On 5/16/2024 8:31 PM, Jan Beulich wrote:
>> On 16.05.2024 12:03, Henry Wang wrote:
>>> --- a/xen/include/public/domctl.h
>>> +++ b/xen/include/public/domctl.h
>>> @@ -1190,6 +1190,17 @@ struct xen_domctl_vmtrace_op {
>>> typedef struct
flight 186026 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186026/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 284dbac43da752ee34825c8b3f6f9e8281cb5a19
baseline version:
ovmf
On 17.05.2024 03:21, Stefano Stabellini wrote:
> On Thu, 16 May 2024, Jan Beulich wrote:
>> 1) In the discussion George claimed that exposing status information in
>> an uncontrolled manner is okay. I'm afraid I have to disagree, seeing
>> how a similar assumption by CPU designers has led to a
flight 186021 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186021/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186013
On 16.05.2024 21:15, Oleksii K. wrote:
> I am not deeply familiar with the technical details surrounding XSM,
> but if I understand Daniel's point correctly, the original change
> violates the access control framework. This suggests to me that the
> revert should be merged.
>
> However, I have a
On Thu, May 16, 2024 at 06:13:29PM +0100, Andrew Cooper wrote:
> On 15/05/2024 4:29 pm, Roger Pau Monne wrote:
> > Print the CPU affinity masks as numeric ranges instead of plain hexadecimal
> > bitfields.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > xen/arch/x86/irq.c | 10 +-
> >
On 5/16/2024 6:03 PM, Henry Wang wrote:
From: Vikram Garhwal
Currently, routing/removing physical interrupts are only allowed at
the domain creation/destroy time. For use cases such as dynamic device
tree overlay adding/removing, the routing/removing of physical IRQ to
running domains
89 matches
Mail list logo
