Re: [PATCH 0/3] Early Boot Allocation on Power

[Jan Beulich]

On 01.12.2023 20:59, Shawn Anastasio wrote:
> Hello all,
> 
> This series enables the Xen boot time allocator on Power by parsing
> the available memory regions from the firmware-provided device tree.
> 
> The device tree processing and bookkeeping code was adapted from Arm,
> but it was trimmed down to exclude code for parsing Arm-specific dt
> nodes.
> 
> Additionally, the final patch of the series updates the radix mmu
> code to use the newly-enabled boot allocator for the Partition and
> Process tables, instead of statically allocating them like was
> previously done. Among other things, switching to run-time allocation
> allows us to allocate a full-sized Process Table instead of the
> minimal one that was previously used to keep the Xen binary size small.
> 
> Thanks,
> 
> Shawn Anastasio (3):
>   xen/ppc: Enable Boot Allocator

A standalone patch with this title was sent earlier. What's their
interrelation?

Jan

>   xen/ppc: mm-radix: Replace debug printing code with printk
>   xen/ppc: mm-radix: Allocate Partition and Process Tables at runtime
> 
>  xen/arch/ppc/Makefile|   1 +
>  xen/arch/ppc/bootfdt.c   | 507 +++
>  xen/arch/ppc/include/asm/setup.h | 113 +++
>  xen/arch/ppc/mm-radix.c  | 197 ++--
>  xen/arch/ppc/setup.c | 109 ++-
>  5 files changed, 823 insertions(+), 104 deletions(-)
>  create mode 100644 xen/arch/ppc/bootfdt.c
> 
> --
> 2.30.2
> 

Re: [RFC KERNEL PATCH v2 1/3] xen/pci: Add xen_reset_device_state function

[Thomas Gleixner]

On Fri, Nov 24 2023 at 18:31, Jiqian Chen wrote:
> When device on dom0 side has been reset, the vpci on Xen side
> won't get notification, so that the cached state in vpci is
> all out of date with the real device state.
> To solve that problem, this patch add a function to clear all

Please get rid of 'this patch' all over the series.

# grep -r 'This patch' Documentation/process/

> vpci device state when device is reset on dom0 side.
>
> And call that function in pcistub_init_device. Because when
> we use "pci-assignable-add" to assign a passthrough device in
> Xen, it will reset passthrough device and the vpci state will
> out of date, and then device will fail to restore bar state.
>
> Signed-off-by: Jiqian Chen 
> Signed-off-by: Huang Rui 

This Signed-off-by chain is incorrect.

Documentation/process/submitting-patches.rst has a full chapter about
S-O-B and the correct usage.

Thanks,

tglx

[RFC XEN PATCH] xen/arm: ffa: reclaim shared memory on guest destroy

[Jens Wiklander]

When an FF-A enabled guest is destroyed it may leave behind memory
shared with SPs. This memory must be reclaimed before it's reused or an
SP may make changes to memory used by a new unrelated guest. So when the
domain is teared down add FF-A requests to reclaim all remaining shared
memory.

SPs in the secure world are notified using VM_DESTROYED that a guest has
been destroyed. An SP is supposed to relinquish all shared memory to allow
reclaiming the memory. The relinquish operation may need to be delayed if
the shared memory is for instance part of a DMA operation.

If the FF-A memory reclaim request fails, return -ERESTART to retry
again. This will effectively block the destruction of the guest until
all memory has been reclaimed.

Signed-off-by: Jens Wiklander 
---
Hi,

This patch is a bit crude, but gets the job done. In a well designed
system this might even be good enough since the SP or the secure world
will let the memory be reclaimed and we can move on. But, if for some
reason reclaiming the memory is refused it must not be possible to reuse
the memory.

These shared memory ranges are typically quite small compared to the
total memory usage of a guest so it would be an improvement if only
refused shared memory ranges where set aside from future reuse while the
guest was destroyed and other resources made available for reuse. This
could be done by for instance assign the refused shared memory ranges
to a dummy VM like DOMID_IO.

Thanks,
Jens
---
 xen/arch/arm/tee/ffa.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 183528d13388..9c596462a8a2 100644
--- a/xen/arch/arm/tee/ffa.c
+++ b/xen/arch/arm/tee/ffa.c
@@ -1539,6 +1539,7 @@ static bool is_in_subscr_list(const uint16_t *subscr, 
uint16_t start,
 static int ffa_domain_teardown(struct domain *d)
 {
 struct ffa_ctx *ctx = d->arch.tee;
+struct ffa_shm_mem *shm, *tmp;
 unsigned int n;
 int32_t res;
 
@@ -1564,10 +1565,45 @@ static int ffa_domain_teardown(struct domain *d)
 printk(XENLOG_ERR "ffa: Failed to report destruction of vm_id %u 
to  %u: res %d\n",
get_vm_id(d), subscr_vm_destroyed[n], res);
 }
+/*
+ * If this function is called again due to -ERESTART below, make sure
+ * not to send the FFA_MSG_SEND_VM_DESTROYED's.
+ */
+subscr_vm_destroyed_count = 0;
 
 if ( ctx->rx )
 rxtx_unmap(ctx);
 
+
+list_for_each_entry_safe(shm, tmp, >shm_list, list)
+{
+register_t handle_hi;
+register_t handle_lo;
+
+uint64_to_regpair(_hi, _lo, shm->handle);
+res = ffa_mem_reclaim(handle_lo, handle_hi, 0);
+if ( res )
+{
+printk(XENLOG_INFO, "ffa: Failed to reclaim handle %#lx : %d\n",
+   shm->handle, res);
+}
+else
+{
+printk(XENLOG_DEBUG, "ffa: Reclaimed handle %#lx\n", shm->handle);
+ctx->shm_count--;
+list_del(>list);
+}
+}
+if ( !list_empty(>shm_list) )
+{
+printk(XENLOG_INFO, "ffa: Remaining unclaimed handles, retrying\n");
+/*
+ * TODO: add a timeout where we either panic or let the guest be
+ * fully destroyed.
+ */
+return -ERESTART;
+}
+
 XFREE(d->arch.tee);
 
 return 0;
-- 
2.34.1

Re: [PATCH v4 2/6] x86/hvm: Allow access to registers on the same page as MSI-X table

[Jan Beulich]

On 02.12.2023 04:07, Marek Marczykowski-Górecki wrote:
> On Mon, Nov 27, 2023 at 06:00:57PM +0100, Jan Beulich wrote:
>> On 24.11.2023 02:47, Marek Marczykowski-Górecki wrote:
>>> +if ( !msix->adj_access_idx[adj_type] )
>>> +{
>>> +gprintk(XENLOG_WARNING,
>>> +"Page for adjacent(%d) MSI-X table access not initialized 
>>> for %pp (addr %#lx, gtable %#lx\n",
>>> +adj_type, >pdev->sbdf, addr, entry->gtable);
>>> +
>>> +return ADJACENT_DONT_HANDLE;
>>> +}
>>> +
>>> +/* If PBA lives on the same page too, discard writes. */
>>> +if ( write &&
>>> + ((adj_type == ADJ_IDX_LAST &&
>>> +   msix->table.last == msix->pba.first) ||
>>> +  (adj_type == ADJ_IDX_FIRST &&
>>> +   msix->table.first == msix->pba.last)) )
>>> +{
>>> +gprintk(XENLOG_WARNING,
>>> +"MSI-X table and PBA of %pp live on the same page, "
>>> +"writing to other registers there is not implemented\n",
>>> +>pdev->sbdf);
>>
>> Here and above I think verbosity needs limiting to the first instance per
>> device per domain.
> 
> Is there some clever API for that already, or do I need to introduce
> extra variable in some of those structures (msixtbl_entry? pci_dev?) ?

Sadly there isn't, and to be honest I also can't really see how one would
go about generalizing / abstracting this.

Jan

Re: [PATCH v2] xen: address violations of MISRA C:2012 Rule 11.8.

[Jan Beulich]

On 01.12.2023 14:44, Simone Ballarin wrote:
> On 01/12/23 14:03, Jan Beulich wrote:
>> On 01.12.2023 12:48, Julien Grall wrote:
>>> On 01/12/2023 11:37, Simone Ballarin wrote:
 --- a/xen/arch/arm/include/asm/regs.h
 +++ b/xen/arch/arm/include/asm/regs.h
 @@ -48,7 +48,7 @@ static inline bool regs_mode_is_32bit(const struct 
 cpu_user_regs *regs)

static inline bool guest_mode(const struct cpu_user_regs *r)
{
 -unsigned long diff = (char *)guest_cpu_user_regs() - (char *)(r);
 +unsigned long diff = (const uintptr_t)guest_cpu_user_regs() - (const 
 uintptr_t)(r);
>>>
>>> NIT: The const should not be necessary here. Am I correct?
>>>
 --- a/xen/arch/x86/include/asm/regs.h
 +++ b/xen/arch/x86/include/asm/regs.h
 @@ -6,7 +6,8 @@

#define guest_mode(r)   
   \
({  
   \
 -unsigned long diff = (char *)guest_cpu_user_regs() - (char *)(r); 
 \
 +unsigned long diff = (const uintptr_t)guest_cpu_user_regs() - 
 \
 +(const 
 uintptr_t(r)); \
>>>
>>> Was this compiled on x86? Shouldn't the last one be (const uintptr_t)(r))?
>>
>> And again with the stray const-s dropped and with indentation adjusted.
>>
> 
> I will remove the const in the first parameter and fix the indentation
> in the following way:
> 
> unsigned long diff = (uintptr_t)guest_cpu_user_regs() -\
>   (const uintptr_t)(r); \

That still looks to be one off, but (supported by the \ placement) possibly
merely an artifact of how your or my mail client is configured. It looks
right at https://lists.xen.org/archives/html/xen-devel/2023-12/msg00057.html.

Jan

Re: [XEN PATCH v2 3/3] xen: address violations of MISRA C:2012 Rule 13.1

[Jan Beulich]

On 02.12.2023 04:22, Stefano Stabellini wrote:
> On Mon, 27 Nov 2023, Jan Beulich wrote:
>> On 24.11.2023 18:29, Simone Ballarin wrote:
>>> Rule 13.1: Initializer lists shall not contain persistent side effects
>>>
>>> The assignment operation in:
>>>
>>> .irq = rc = uart->irq,
>>>
>>> is a persistent side effect in a struct initializer list.
>>>
>>> This patch avoids rc assignment and directly uses uart->irq
>>> in the following if statement.
>>>
>>> No functional changes.
>>>
>>> Signed-off-by: Maria Celeste Cesario  
>>> Signed-off-by: Simone Ballarin 
>>
>> Who's the author of this patch? (Either the order of the SoB is wrong, or
>> there's a From: tag missing.)
>>
>>> ---
>>> Changes in v2:
>>> - avoid assignment of rc;
>>> - drop changes in vcpu_yield(void).
>>> ---
>>>  xen/drivers/char/ns16550.c | 6 --
>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> This warrants a more specific subject prefix. Also there's only a single
>> violation being dealt with here.
>>
>>> --- a/xen/drivers/char/ns16550.c
>>> +++ b/xen/drivers/char/ns16550.c
>>> @@ -445,11 +445,13 @@ static void __init cf_check 
>>> ns16550_init_postirq(struct serial_port *port)
>>>  struct msi_info msi = {
>>>  .sbdf = PCI_SBDF(0, uart->ps_bdf[0], uart->ps_bdf[1],
>>>   uart->ps_bdf[2]),
>>> -.irq = rc = uart->irq,
>>> +.irq = uart->irq,
>>>  .entry_nr = 1
>>>  };
>>>  
>>> -if ( rc > 0 )
>>> +rc = 0;
>>> +
>>> +if ( uart->irq > 0 )
>>>  {
>>>  struct msi_desc *msi_desc = NULL;
>>
>> The fact that there's no functional change here isn't really obvious.
>> Imo you want to prove that to a reasonable degree in the description.
>  
> Agreed. Only reading this chunk, wouldn't it be better to do:
> 
> };
> 
> rc = uart->irq;
> 
> if ( rc > 0 )
> 
> at least it would be obvious?

Indeed.

Jan

Re: [XEN PATCH 7/7] xen/page_alloc: deviate first_valid_mfn for MISRA C Rule 8.4

[Jan Beulich]

On 02.12.2023 04:03, Stefano Stabellini wrote:
> On Fri, 1 Dec 2023, Jan Beulich wrote:
>> On 01.12.2023 03:47, Stefano Stabellini wrote:
>>> On Wed, 29 Nov 2023, Nicola Vetrini wrote:
 No functional change.

 Signed-off-by: Nicola Vetrini 
 ---
 The preferred way to deviate is to use asmlinkage, but this modification 
 is only
 the consequence of NUMA on ARM (and possibly PPC) being a work in progress.
 As stated in the comment above the textual deviation, first_valid_mfn will
 likely then become static and there would be no need for the comment 
 anymore.
 This works towards having the analysis for this rule clean (i.e. no 
 violations);
 the interest in having a clean rule is that then it could be used to signal
 newly introduced violations by making the analysis job fail.
>>>
>>> Please add this text as part of the commit message. It can be done on
>>> commit.
>>
>> I assume you saw my reply on another of the patches in this series as to
>> asmlinkage use on variables? IOW I think this paragraph would also need
>> adjustment to account for that.
> 
> I was going to ask you about that: reading your reply
> https://marc.info/?l=xen-devel=170142048615336 it is not clear to me
> what you are asking or suggesting as next step in regard to asmlinkage
> use on variables.

Either we need a separate attribute, or we need affirmation that calling
convention attributes are ignored (and going to be going forward) for
variables, or we need to resort to SAF-* comments. I'm not sure what's
best (assuming the "affirm" wouldn't really be possible).

Jan

[linux-linus test] 183982: regressions - FAIL

[osstest service owner]

flight 183982 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183982/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  6 kernel-build fail REGR. vs. 183973

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 183973
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183973
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 183973
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 183973
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 183973
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 183973
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 183973
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 183973
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-vhd  14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass

version targeted for testing:
 linux33cc938e65a98f1d29d0a18403dbbee050dcad9a
baseline version:
 linux815fb87b753055df2d9e50f6cd80eb10235fe3e9

Last test of basis   183973  2023-12-02 07:48:26 Z1 days
Failing since183977  2023-12-03 00:12:06 Z1 days4 attempts
Testing same since   183981  2023-12-03 18:14:02 Z0 days2 attempts


People who touched revisions under test:
  Alex Williamson 
  Brett Creeley 
  Dan Carpenter 
  David Howells 
  Dmitry Antipov 
  Jens Axboe 
  JP Kobryn 
  Juergen Gross 
  Linus Torvalds 
  Masami Hiramatsu (Google) 
  Michael Ellerman 
  Namjae Jeon 
  Nicholas Piggin 
  Paulo Alcantara (SUSE) 
  Paulo Alcantara 
  Sean Christopherson 
  Steve French 
  Takashi Sakamoto 
  Timothy Pearson 
  wuqiang.matt 
  Yang Yingliang 

jobs:
 build-amd64-xsm  pass
 

Re: Trying add smt=off disabled cores to cpupool crash xen

[Juergen Gross]

On 01.12.23 21:12, Andrew Cooper wrote:

On 01/12/2023 7:59 pm, René Winther Højgaard wrote:

If I set smt=off and try to configure cpupools with credit(1) as if
all cores are available, I get the following crash.

The crash happens when I try to use xl cpupool-add-cpu on the disabled
HT sibling cores.

Hyper-threading is enabled in the firmware, and only disabled with
smt=off.


CC'ing some maintainers.


Attached patch should fix the crash.

René, are you fine with the "Reported-by:" tag being added to the patch?

I'll send a proper patch mail when having heard from you.


Juergen
From 65c70cc53df3a71225b11cb95848f12f5a565d5d Mon Sep 17 00:00:00 2001
From: Juergen Gross 
Date: Mon, 4 Dec 2023 08:00:21 +0100
Subject: [PATCH] xen/sched: fix adding offline cpu to cpupool
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Trying to add an offline cpu to a cpupool can crash the hypervisor,
as the probably non-existing percpu area of the cpu is accessed before
the availability of the cpu is being tested.

Fix that by testing the cpu to be online.

Fixes: cb563d7665f2 ("xen/sched: support core scheduling for moving cpus to/from cpupools")
Reported-by: René Winther Højgaard 
Signed-off-by: Juergen Gross 
---
 xen/common/sched/cpupool.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/common/sched/cpupool.c b/xen/common/sched/cpupool.c
index 2e094b0cfa..ad8f608462 100644
--- a/xen/common/sched/cpupool.c
+++ b/xen/common/sched/cpupool.c
@@ -892,6 +892,8 @@ int cpupool_do_sysctl(struct xen_sysctl_cpupool_op *op)
 if ( cpu >= nr_cpu_ids )
 goto addcpu_out;
 ret = -ENODEV;
+if ( !cpu_online(cpu) )
+goto addcpu_out;
 cpus = sched_get_opt_cpumask(c->gran, cpu);
 if ( !cpumask_subset(cpus, _free_cpus) ||
  cpumask_intersects(cpus, _locked_cpus) )
-- 
2.35.3



OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [RFC XEN PATCH v2 1/3] xen/vpci: Clear all vpci status of device

[Chen, Jiqian]

Hi Daniel P. Smith,

On 2023/11/30 22:52, Roger Pau Monné wrote:
> On Thu, Nov 30, 2023 at 07:39:38AM -0500, Daniel P. Smith wrote:
>> On 11/30/23 07:25, Daniel P. Smith wrote:
>>> On 11/30/23 01:22, Chen, Jiqian wrote:
 Hi Roger and Daniel P. Smith,

 On 2023/11/28 22:08, Roger Pau Monné wrote:
> On Fri, Nov 24, 2023 at 06:41:34PM +0800, Jiqian Chen wrote:
>> When a device has been reset on dom0 side, the vpci on Xen
>> side won't get notification, so the cached state in vpci is
>> all out of date compare with the real device state.
>> To solve that problem, this patch add new hypercall to clear
>> all vpci device state. And when reset device happens on dom0
>> side, dom0 can call this hypercall to notify vpci.
>>
>> Signed-off-by: Jiqian Chen 
>> Signed-off-by: Huang Rui 
>> ---
>>   xen/arch/x86/hvm/hypercall.c  |  1 +
>>   xen/drivers/passthrough/pci.c | 21 +
>>   xen/drivers/pci/physdev.c | 14 ++
>>   xen/drivers/vpci/vpci.c   |  9 +
>>   xen/include/public/physdev.h  |  2 ++
>>   xen/include/xen/pci.h |  1 +
>>   xen/include/xen/vpci.h    |  6 ++
>>   7 files changed, 54 insertions(+)
>>
>> diff --git a/xen/arch/x86/hvm/hypercall.c
>> b/xen/arch/x86/hvm/hypercall.c
>> index eeb73e1aa5..6ad5b4d5f1 100644
>> --- a/xen/arch/x86/hvm/hypercall.c
>> +++ b/xen/arch/x86/hvm/hypercall.c
>> @@ -84,6 +84,7 @@ long hvm_physdev_op(int cmd,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>   case PHYSDEVOP_pci_mmcfg_reserved:
>>   case PHYSDEVOP_pci_device_add:
>>   case PHYSDEVOP_pci_device_remove:
>> +    case PHYSDEVOP_pci_device_state_reset:
>>   case PHYSDEVOP_dbgp_op:
>>   if ( !is_hardware_domain(currd) )
>>   return -ENOSYS;
>> diff --git a/xen/drivers/passthrough/pci.c
>> b/xen/drivers/passthrough/pci.c
>> index 04d00c7c37..f871715585 100644
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -824,6 +824,27 @@ int pci_remove_device(u16 seg, u8 bus, u8 devfn)
>>   return ret;
>>   }
>> +int pci_reset_device_state(u16 seg, u8 bus, u8 devfn)
>
> You could use pci_sbdf_t here instead of 3 parameters.
 Will change in next version, thank you.

>
> I'm however unsure whether we really need this helper just to fetch
> the pdev and call vpci_reset_device_state(), I think you could place
> this logic directly in pci_physdev_op().  Unless there are plans to
> use such logic outside of pci_physdev_op().
 If I place the logic of pci_reset_device_state directly in
 pci_physdev_op. I think I need to declare vpci_reset_device_state in
 pci.h? If it is suitable, I will change in next version.

>
>> +{
>> +    struct pci_dev *pdev;
>> +    int ret = -ENODEV;
>
> Some XSM check should be introduced fro this operation, as none of the
> existing ones is suitable.  See xsm_resource_unplug_pci() for example.
>
> xsm_resource_reset_state_pci() or some such I would assume.
 I don't know what I should do in XSM function(assume it is
 xsm_resource_reset_state_pci).
 Hi Daniel P. Smith, could you please give me some suggestions?
 Just to check the XSM_PRIV action?

>>>
>>> Roger, thank you for seeing this and adding me in!
>>>
>>> Jiqian, I just wanted to let you know I have seen your post but I have
>>> been a little tied up this week. Just with the cursory look, I think
>>> Roger is suggesting a new XSM check/hook is warranted.
>>>
>>> If you would like to attempt at writing the dummy policy side, mimic
>>> xsm_resource_plug_pci in xen/include/xsm/dummy.h and
>>> xen/include/xsm/xsm.h, then I can look at handling the FLASK portion
>>> next week and provide it to you for inclusion into the series. If you
>>> are not comfortable with it, I can look at the whole thing next week.
>>> Just let me know what you would be comfortable with.
>>
>> Apologies, thinking about for a moment and was thinking the hook should be
>> called xsm_resource_config_pci. I would reset as a config operation and
>> there might be new ones in the future. I do not believe there is a need to
>> have fine grain access control down to individual config operation, thus
>> they could all be captured under this one hook. Roger, what are your
>> thoughts about this, in particular how you see vpci evolving?
> 
> So the configuration space reset should only be done by the domain
> that's also capable of triggering the physical device reset, usually
> the hardware domain.  I don't think it's possible ATM to allow a
> domain different than the hardware domain to perform a PCI reset, as
> doing it requires unmediated access to the PCI config space.
> 
> So resetting the vPCI state should either be limited to the hardware
> domain, or to a pci reset capability 

Re: [linux-linus test] 183981: regressions - FAIL

[Juergen Gross]

On 04.12.23 00:51, osstest service owner wrote:

flight 183981 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183981/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
  build-i386-pvops  6 kernel-build fail REGR. vs. 183973


This test is nonsense. We don't support running on a Pentium-Pro, which is the
configured processor for the kernel.

We should do a 32-bit build using a more recent processor model.


  build-arm64-pvops 6 kernel-build fail REGR. vs. 183973


This one failed with:

gcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[5]: *** [scripts/Makefile.build:243: drivers/clk/hisilicon/clk.o] Error 4
make[4]: *** [scripts/Makefile.build:480: drivers/clk/hisilicon] Error 2
make[3]: *** [scripts/Makefile.build:480: drivers/clk] Error 2


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [RFC XEN PATCH v2 3/3] tools: Add new function to get gsi from irq

[Chen, Jiqian]

On 2023/12/1 17:03, Roger Pau Monné wrote:
> On Thu, Nov 30, 2023 at 07:09:12PM -0800, Stefano Stabellini wrote:
>> On Thu, 30 Nov 2023, Roger Pau Monné wrote:
>>> On Wed, Nov 29, 2023 at 08:02:40PM -0800, Stefano Stabellini wrote:
 n Wed, 29 Nov 2023, Stefano Stabellini wrote:
> On Tue, 28 Nov 2023, Roger Pau Monné wrote:
>> On Fri, Nov 24, 2023 at 06:41:36PM +0800, Jiqian Chen wrote:
>>> In PVH dom0, it uses the linux local interrupt mechanism,
>>> when it allocs irq for a gsi, it is dynamic, and follow
>>> the principle of applying first, distributing first. And
>>> if you debug the kernel codes, you will find the irq
>>> number is alloced from small to large, but the applying
>>> gsi number is not, may gsi 38 comes before gsi 28, that
>>> causes the irq number is not equal with the gsi number.
>>> And when we passthrough a device, QEMU will use its gsi
>>> number to do mapping actions, see xen_pt_realize->
>>> xc_physdev_map_pirq, but the gsi number is got from file
>>> /sys/bus/pci/devices/:xx:xx.x/irq in current code,
>>> so it will fail when mapping.
>>> And in current codes, there is no method to translate
>>> irq to gsi for userspace.
>>
>> I think it would be cleaner to just introduce a new sysfs node that
>> contains the gsi if a device is using one (much like the irq sysfs
>> node)?
>>
>> Such ioctl to translate from IRQ to GSI has nothing to do with Xen, so
>> placing it in privcmd does seem quite strange to me.  I understand
>> that for passthrough we need the GSI, but such translation layer from
>> IRQ to GSI is all Linux internal, and it would be much simpler to just
>> expose the GSI in sysfs IMO.
>
> Maybe something to add to drivers/xen/sys-hypervisor.c in Linux.
> Juergen what do you think?

 Let me also add that privcmd.c is already a Linux specific interface.
 Although it was born to be a Xen hypercall "proxy" in reality today we
 have a few privcmd ioctls that don't translate into hypercalls. So I
 don't think that adding IOCTL_PRIVCMD_GSI_FROM_IRQ would be a problem.
>>>
>>> Maybe not all ioctls translate to hypercalls (I guess you are
>>> referring to the IOCTL_PRIVCMD_RESTRICT ioctl), but they are specific
>>> Xen actions.  Getting the GSI used by a device has nothing do to with
>>> Xen.
>>>
>>> IMO drivers/xen/sys-hypervisor.c is also not appropriate, but I'm not
>>> the maintainer of any of those components.
>>>
>>> There's nothing Xen specific about fetching the GSI associated with a
>>> PCI device.  The fact that Xen needs it for passthrough is just a red
>>> herring, further cases where the GSI is needed might arise outside of
>>> Xen, and hence such node would better be placed in a generic
>>> location.  The right location should be /sys/bus/pci/devices//gsi.
>>
>> That might be true but /sys/bus/pci/devices//gsi is a non-Xen
>> generic interface and the maintainers of that portion of Linux code
>> might have a different opinion. We'll have to see.
> 
> Right, but before resorting to implement a Xen specific workaround
> let's attempt to do it the proper way :).
> 
> I cannot see why exposing the gsi on sysfs like that would be an
> issue.  There's a lot of resource information exposed on sysfs
> already, and it's a trivial node to implement.
Thanks for both of you' s suggestions. At present, it seems the result of 
discussion is that it needs to add a gsi sysfs. I will modify it in the next 
version and then add the corresponding maintainer to the review list.

> 
> Thanks, Roger.

-- 
Best regards,
Jiqian Chen.

Re: INFORMAL VOTE REQUIRED - DOCUMENTATION WORDING

[Kelly Choi]

Hi everyone,

Thank you for your feedback.

Firstly, let me apologise if I have caused confusion with the form. It was
not intended to be a one answer fits all within the community. Rather, it
was created to give community members an option to share how they feel
about the term, with the example mentioned. In the future, I want to ensure
you that I have taken your feedback on board and wider context will be
provided. I'll also make sure that maintainers/committers are CC'd into the
threads.

The form was created as a method to understand the wider view of the
community, whilst making it easier to track responses. The key takeaways
here are what Stefano has addressed earlier: that we should reach a
consensus quicker rather than continue what some would consider nitpicking
small things.

Following the discussions above and my previous emails, we will be adding
informal voting to the governance guidelines and reviewing other ways to
better collaborate. Some suggestions for improvement include discussing
ways in which the wider community can address their concerns, having the
ability to vote, and potentially electing an arbiter or technical steering
committee for similar situations. I will be sending out further
communications and discussing this with the community at a later date.

In the specific example above, it's difficult in the sense that informal
voting wasn't officially in the governance yet when the feedback was
raised. What I would recommend in this instance is that if George and
others feel very strongly about removing that term and have given a proper
explanation, then I'd advise calling an informal vote within the thread and
following the decision. Alternatively if after this conversation, members
understand Andy's point of view and the term doesn't have serious
consequences - let's agree with what Andy inputted in the first place and
move this project ahead.  In an ideal world, we wouldn't require voting,
but rather a discussion. However, if there are strong opinions for/against
a specific decision that is causing us to be at a standstill, this is where
informal voting helps.

*I have updated the form

with wider context and other options to reflect a 5-point survey, should
anyone wish to express/change their vote. It would be good to view how the
community feels about this in general, which should guide us in future
similar situations. *

I just want to reiterate that we all working towards a common goal within
the project, and although disagreements can arise, we should always seek
ways to compromise.

Many thanks,
Kelly Choi

Xen Project Community Manager
XenServer, Cloud Software Group


On Fri, Dec 1, 2023 at 11:03 PM George Dunlap 
wrote:

> On Fri, Dec 1, 2023 at 9:44 PM Stefano Stabellini
>  wrote:
> > By the informal
> > voting, we have 3 against "broken" and 2 in favor (not 1 as George wrote
> > as Andrew's vote counts too).
>
> Just to clarify: The opinions on that thread (if you include all
> versions of the series) were:
>
> Andy, Daniel for keeping "broken
> Julien, Jan, Stefano, George: for changing "broken"
>
> That's the "2 (+) / 4 split" I referred to (The "(+)" being the people
> who agreed with Andy in private).  Regarding voting, I was only
> counting the maintainers of the code in question; it coming under THE
> REST, that would include everyone except Daniel; hence 1 - 4.  Not at
> all that Daniel's opinion doesn't matter, but that from a governance
> perspective, it's the maintainers (and then the committers) who get
> votes in the case of a formal escalation.
>
>  -George
>

Re: [PATCH v6 4/5] [FUTURE] xen/arm: enable vPCI for domUs

[Stewart Hildebrand]

On 12/1/23 21:56, Stefano Stabellini wrote:
> On Fri, 1 Dec 2023, Roger Pau Monné wrote:
>> On Mon, Nov 13, 2023 at 05:21:13PM -0500, Stewart Hildebrand wrote:
>>> @@ -1618,6 +1630,14 @@ int iommu_do_pci_domctl(
>>>  bus = PCI_BUS(machine_sbdf);
>>>  devfn = PCI_DEVFN(machine_sbdf);
>>>  
>>> +if ( needs_vpci(d) && !has_vpci(d) )
>>> +{
>>> +printk(XENLOG_G_WARNING "Cannot assign %pp to %pd: vPCI 
>>> support not enabled\n",
>>> +   _SBDF(seg, bus, devfn), d);
>>> +ret = -EPERM;
>>> +break;
>>
>> I think this is likely too restrictive going forward.  The current
>> approach is indeed to enable vPCI on a per-domain basis because that's
>> how PVH dom0 uses it, due to being unable to use ioreq servers.
>>
>> If we start to expose vPCI suport to guests the interface should be on
>> a per-device basis, so that vPCI could be enabled for some devices,
>> while others could still be handled by ioreq servers.
>>
>> We might want to add a new flag to xen_domctl_assign_device (used by
>> XEN_DOMCTL_assign_device) in order to signal whether the device will
>> use vPCI.
> 
> Actually I don't think this is a good idea. I am all for flexibility but
> supporting multiple different configurations comes at an extra cost for
> both maintainers and contributors. I think we should try to reduce the
> amount of configurations we support rather than increasing them
> (especially on x86 where we have PV, PVH, HVM).
> 
> I don't think we should enable IOREQ servers to handle PCI passthrough
> for PVH guests and/or guests with vPCI. If the domain has vPCI, PCI
> Passthrough can be handled by vPCI just fine. I think this should be a
> good anti-feature to have (a goal to explicitly not add this feature) to
> reduce complexity. Unless you see a specific usecase to add support for
> it?

Just to preemptively clarify: there is a use case for passthrough (vPCI) and 
emulated virtio-pci devices (ioreq). However, the XEN_DOMCTL_assign_device 
hypercall, where this check is added, is only used for real physical hardware 
devices as far as I can tell. So I agree, I can't see a use case for passing 
through some physical devices with vPCI and some physical devices with 
qemu/ioreq.

With that said, the plumbing for a new flag does not appear to be particularly 
complex. It may actually be simpler than introducing a per-arch needs_vpci(d) 
heuristic.

diff --git a/tools/libs/light/libxl_pci.c b/tools/libs/light/libxl_pci.c
index 96cb4da0794e..2c38088a4772 100644
--- a/tools/libs/light/libxl_pci.c
+++ b/tools/libs/light/libxl_pci.c
@@ -1113,6 +1113,7 @@ typedef struct pci_add_state {
 libxl_device_pci pci;
 libxl_domid pci_domid;
 int retries;
+bool vpci;
 } pci_add_state;

 static void pci_add_qemu_trad_watch_state_cb(libxl__egc *egc,
@@ -1176,6 +1177,10 @@ static void do_pci_add(libxl__egc *egc,
 }
 }

+if (type == LIBXL_DOMAIN_TYPE_PVH /* includes Arm guests */) {
+pas->vpci = true;
+}
+
 rc = 0;

 out:
@@ -1418,7 +1423,8 @@ static void pci_add_dm_done(libxl__egc *egc,
 unsigned long long start, end, flags, size;
 int irq, i;
 int r;
-uint32_t flag = XEN_DOMCTL_DEV_RDM_RELAXED;
+uint32_t flag = XEN_DOMCTL_DEV_RDM_RELAXED |
+(pas->vpci ? XEN_DOMCTL_DEV_USES_VPCI : 0);
 uint32_t domainid = domid;
 bool isstubdom = libxl_is_stubdom(ctx, domid, );

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 2203725a2aa6..7786da1cf1e6 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1630,7 +1630,7 @@ int iommu_do_pci_domctl(
 bus = PCI_BUS(machine_sbdf);
 devfn = PCI_DEVFN(machine_sbdf);

-if ( needs_vpci(d) && !has_vpci(d) )
+if ( (flags & XEN_DOMCTL_DEV_USES_VPCI) && !has_vpci(d) )
 {
 printk(XENLOG_G_WARNING "Cannot assign %pp to %pd: vPCI support 
not enabled\n",
_SBDF(seg, bus, devfn), d);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 8b3ea62cae06..5735d47219bc 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -527,6 +527,7 @@ struct xen_domctl_assign_device {
 uint32_t dev;   /* XEN_DOMCTL_DEV_* */
 uint32_t flags;
 #define XEN_DOMCTL_DEV_RDM_RELAXED  1 /* assign only */
+#define XEN_DOMCTL_DEV_USES_VPCI(1 << 1)
 union {
 struct {
 uint32_t machine_sbdf;   /* machine PCI ID of assigned device */

Re: [RFC KERNEL PATCH v2 1/3] xen/pci: Add xen_reset_device_state function

[Stewart Hildebrand]

On 12/3/23 22:25, Chen, Jiqian wrote:
> Hi Stewart,
> 
> On 2023/11/30 23:03, Stewart Hildebrand wrote:
>> On 11/30/23 02:03, Chen, Jiqian wrote:
>>>
>>> On 2023/11/30 11:46, Stefano Stabellini wrote:
 On Fri, 24 Nov 2023, Jiqian Chen wrote:
> When device on dom0 side has been reset, the vpci on Xen side
> won't get notification, so that the cached state in vpci is
> all out of date with the real device state.
> To solve that problem, this patch add a function to clear all
> vpci device state when device is reset on dom0 side.
>
> And call that function in pcistub_init_device. Because when
> we use "pci-assignable-add" to assign a passthrough device in
> Xen, it will reset passthrough device and the vpci state will
> out of date, and then device will fail to restore bar state.
>
> Signed-off-by: Jiqian Chen 
> Signed-off-by: Huang Rui 
> ---
>  drivers/xen/pci.c  | 12 
>  drivers/xen/xen-pciback/pci_stub.c |  3 +++
>  include/xen/interface/physdev.h|  2 ++
>  include/xen/pci.h  |  6 ++
>  4 files changed, 23 insertions(+)
>
> diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
> index 72d4e3f193af..e9b30bc09139 100644
> --- a/drivers/xen/pci.c
> +++ b/drivers/xen/pci.c
> @@ -177,6 +177,18 @@ static int xen_remove_device(struct device *dev)
>   return r;
>  }
>  
> +int xen_reset_device_state(const struct pci_dev *dev)
> +{
> + struct physdev_pci_device device = {
> + .seg = pci_domain_nr(dev->bus),
> + .bus = dev->bus->number,
> + .devfn = dev->devfn
> + };
> +
> + return HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_state_reset, );
> +}
> +EXPORT_SYMBOL_GPL(xen_reset_device_state);
> +
>  static int xen_pci_notifier(struct notifier_block *nb,
>   unsigned long action, void *data)
>  {
> diff --git a/drivers/xen/xen-pciback/pci_stub.c 
> b/drivers/xen/xen-pciback/pci_stub.c
> index e34b623e4b41..5a96b6c66c07 100644
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -421,6 +421,9 @@ static int pcistub_init_device(struct pci_dev *dev)
>   else {
>   dev_dbg(>dev, "resetting (FLR, D3, etc) the device\n");
>   __pci_reset_function_locked(dev);
> + err = xen_reset_device_state(dev);
> + if (err)
> + goto config_release;

 Older versions of Xen won't have the hypercall
 PHYSDEVOP_pci_device_state_reset implemented. I think we should do
 something like:

 if (err && xen_pvh_domain())
 goto config_release;


 Or even:

 if (xen_pvh_domain()) {
 err = xen_reset_device_state(dev);
 if (err)
 goto config_release;
 }

 depending on whether we want to call xen_reset_device_state also for PV
 guests or not. I am assuming we don't want to error out on failure such
 as -ENOENT for PV guests.
>>> Yes, only for PVH dom0, I will add the condition in next version. Thank you!
>>
>> We will want to call xen_reset_device_state() for Arm dom0, too, so checking 
>> xen_pvh_domain() alone is not sufficient. I suggest instead to check 
>> !xen_pv_domain().
> I am not using Arm. But is Arm dom0 not a PVH type dom0?

Apparently not, Arm dom0 appears to be a xen_hvm_domain() from the kernel's 
perspective.

> 
>>
>>>


>   pci_restore_state(dev);
>   }
>   /* Now disable the device (this also ensures some private device
> diff --git a/include/xen/interface/physdev.h 
> b/include/xen/interface/physdev.h
> index a237af867873..231526f80f6c 100644
> --- a/include/xen/interface/physdev.h
> +++ b/include/xen/interface/physdev.h
> @@ -263,6 +263,8 @@ struct physdev_pci_device {
>  uint8_t devfn;
>  };
>  
> +#define PHYSDEVOP_pci_device_state_reset 32
> +
>  #define PHYSDEVOP_DBGP_RESET_PREPARE1
>  #define PHYSDEVOP_DBGP_RESET_DONE   2
>  
> diff --git a/include/xen/pci.h b/include/xen/pci.h
> index b8337cf85fd1..b2e2e856efd6 100644
> --- a/include/xen/pci.h
> +++ b/include/xen/pci.h
> @@ -4,10 +4,16 @@
>  #define __XEN_PCI_H__
>  
>  #if defined(CONFIG_XEN_DOM0)
> +int xen_reset_device_state(const struct pci_dev *dev);
>  int xen_find_device_domain_owner(struct pci_dev *dev);
>  int xen_register_device_domain_owner(struct pci_dev *dev, uint16_t 
> domain);
>  int xen_unregister_device_domain_owner(struct pci_dev *dev);
>  #else
> +static inline int xen_reset_device_state(const struct pci_dev *dev)
> +{
> + return -1;
> +}
> +
>  static inline int xen_find_device_domain_owner(struct pci_dev *dev)
>  {
>   return -1;
> -- 
> 2.34.1
>
>>>
> 

Re: [RFC KERNEL PATCH v2 1/3] xen/pci: Add xen_reset_device_state function

[Chen, Jiqian]

Hi Stewart,

On 2023/11/30 23:03, Stewart Hildebrand wrote:
> On 11/30/23 02:03, Chen, Jiqian wrote:
>>
>> On 2023/11/30 11:46, Stefano Stabellini wrote:
>>> On Fri, 24 Nov 2023, Jiqian Chen wrote:
 When device on dom0 side has been reset, the vpci on Xen side
 won't get notification, so that the cached state in vpci is
 all out of date with the real device state.
 To solve that problem, this patch add a function to clear all
 vpci device state when device is reset on dom0 side.

 And call that function in pcistub_init_device. Because when
 we use "pci-assignable-add" to assign a passthrough device in
 Xen, it will reset passthrough device and the vpci state will
 out of date, and then device will fail to restore bar state.

 Signed-off-by: Jiqian Chen 
 Signed-off-by: Huang Rui 
 ---
  drivers/xen/pci.c  | 12 
  drivers/xen/xen-pciback/pci_stub.c |  3 +++
  include/xen/interface/physdev.h|  2 ++
  include/xen/pci.h  |  6 ++
  4 files changed, 23 insertions(+)

 diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
 index 72d4e3f193af..e9b30bc09139 100644
 --- a/drivers/xen/pci.c
 +++ b/drivers/xen/pci.c
 @@ -177,6 +177,18 @@ static int xen_remove_device(struct device *dev)
return r;
  }
  
 +int xen_reset_device_state(const struct pci_dev *dev)
 +{
 +  struct physdev_pci_device device = {
 +  .seg = pci_domain_nr(dev->bus),
 +  .bus = dev->bus->number,
 +  .devfn = dev->devfn
 +  };
 +
 +  return HYPERVISOR_physdev_op(PHYSDEVOP_pci_device_state_reset, );
 +}
 +EXPORT_SYMBOL_GPL(xen_reset_device_state);
 +
  static int xen_pci_notifier(struct notifier_block *nb,
unsigned long action, void *data)
  {
 diff --git a/drivers/xen/xen-pciback/pci_stub.c 
 b/drivers/xen/xen-pciback/pci_stub.c
 index e34b623e4b41..5a96b6c66c07 100644
 --- a/drivers/xen/xen-pciback/pci_stub.c
 +++ b/drivers/xen/xen-pciback/pci_stub.c
 @@ -421,6 +421,9 @@ static int pcistub_init_device(struct pci_dev *dev)
else {
dev_dbg(>dev, "resetting (FLR, D3, etc) the device\n");
__pci_reset_function_locked(dev);
 +  err = xen_reset_device_state(dev);
 +  if (err)
 +  goto config_release;
>>>
>>> Older versions of Xen won't have the hypercall
>>> PHYSDEVOP_pci_device_state_reset implemented. I think we should do
>>> something like:
>>>
>>> if (err && xen_pvh_domain())
>>> goto config_release;
>>>
>>>
>>> Or even:
>>>
>>> if (xen_pvh_domain()) {
>>> err = xen_reset_device_state(dev);
>>> if (err)
>>> goto config_release;
>>> }
>>>
>>> depending on whether we want to call xen_reset_device_state also for PV
>>> guests or not. I am assuming we don't want to error out on failure such
>>> as -ENOENT for PV guests.
>> Yes, only for PVH dom0, I will add the condition in next version. Thank you!
> 
> We will want to call xen_reset_device_state() for Arm dom0, too, so checking 
> xen_pvh_domain() alone is not sufficient. I suggest instead to check 
> !xen_pv_domain().
I am not using Arm. But is Arm dom0 not a PVH type dom0?

> 
>>
>>>
>>>
pci_restore_state(dev);
}
/* Now disable the device (this also ensures some private device
 diff --git a/include/xen/interface/physdev.h 
 b/include/xen/interface/physdev.h
 index a237af867873..231526f80f6c 100644
 --- a/include/xen/interface/physdev.h
 +++ b/include/xen/interface/physdev.h
 @@ -263,6 +263,8 @@ struct physdev_pci_device {
  uint8_t devfn;
  };
  
 +#define PHYSDEVOP_pci_device_state_reset 32
 +
  #define PHYSDEVOP_DBGP_RESET_PREPARE1
  #define PHYSDEVOP_DBGP_RESET_DONE   2
  
 diff --git a/include/xen/pci.h b/include/xen/pci.h
 index b8337cf85fd1..b2e2e856efd6 100644
 --- a/include/xen/pci.h
 +++ b/include/xen/pci.h
 @@ -4,10 +4,16 @@
  #define __XEN_PCI_H__
  
  #if defined(CONFIG_XEN_DOM0)
 +int xen_reset_device_state(const struct pci_dev *dev);
  int xen_find_device_domain_owner(struct pci_dev *dev);
  int xen_register_device_domain_owner(struct pci_dev *dev, uint16_t 
 domain);
  int xen_unregister_device_domain_owner(struct pci_dev *dev);
  #else
 +static inline int xen_reset_device_state(const struct pci_dev *dev)
 +{
 +  return -1;
 +}
 +
  static inline int xen_find_device_domain_owner(struct pci_dev *dev)
  {
return -1;
 -- 
 2.34.1

>>

-- 
Best regards,
Jiqian Chen.

Re: [PATCH] x86/x2apic: introduce a mixed physical/cluster mode

[Elliott Mitchell]

On Mon, Nov 27, 2023 at 09:27:18AM +0100, Roger Pau Monn
> On Fri, Nov 24, 2023 at 05:15:34PM -0800, Elliott Mitchell wrote:
> > On Thu, Nov 23, 2023 at 10:39:37AM +0100, Roger Pau Monn
> > > On Tue, Nov 21, 2023 at 04:56:47PM -0800, Elliott Mitchell wrote:
> > > > It was insisted that full logs be sent to xen-devel.  Perhaps I am
> > > > paranoid, but I doubt I would have been successful at scrubbing all
> > > > hardware serial numbers.  As such, I was willing to post substantial
> > > > sections, but not everything.
> > > 
> > > Can you please point out which hardware serial numbers are you
> > > referring to, and where are they printed in Xen dmesg?
> > 
> > I didn't confirm the presence of hardware serial numbers getting into
> > Xen's dmesg, but there was a lot of data and many hexadecimal numbers.
> > With 4000 lines of output, checking for concerning data is troublesome.
> 
> 4000 lines of output from Xen dmesg seems quite suspicious.  Xen dmesg
> on a fully booted box is ~400 lines on my local box.  That might get
> quite longer if you have a box with a lot of memory region, or a lot
> of CPUs.

That was from 4 boots with differing settings.  Since it was full console
log, it also had the initial Linux kernel boot messages.  Each log was
~1000 lines.

> > There was enough for alarms to trigger.
> 
> That's fine, but without pointing out which information is sensitive,
> it's very unlikely such concerns will ever get fixed.
> 
> Could you at least go over the log and point out the first instance of
> such line that you consider contains sensitive information?

I would have been more comfortable with getting some guidance on which
portions were desired or which could be left out.  No need for Linux's
boot messages, what would cut things down by half.  No need for the
memory map, lots more goes.

It is easier to be comfortable with 40 line sections than 1000 line
sections.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

[linux-linus test] 183981: regressions - FAIL

[osstest service owner]

flight 183981 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183981/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  6 kernel-build fail REGR. vs. 183973
 build-arm64-pvops 6 kernel-build fail REGR. vs. 183973

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 183973
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183973
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 183973
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 183973
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 183973
 test-armhf-armhf-xl-credit1   8 xen-boot fail  like 183973
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 183973
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 183973
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 183973
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass

version targeted for testing:
 linux33cc938e65a98f1d29d0a18403dbbee050dcad9a
baseline version:
 linux815fb87b753055df2d9e50f6cd80eb10235fe3e9

Last test of basis   183973  2023-12-02 07:48:26 Z1 days
Failing since183977  2023-12-03 00:12:06 Z0 days3 attempts
Testing same since   183981  2023-12-03 18:14:02 Z0 days1 attempts


People who touched revisions under test:
  Alex Williamson 
  Brett Creeley 
  Dan Carpenter 
  David Howells 
  Dmitry Antipov 
  Jens Axboe 
  JP Kobryn 
  Juergen Gross 
  Linus Torvalds 
  Masami Hiramatsu (Google) 
  Michael Ellerman 
  Namjae Jeon 
  Nicholas Piggin 
  Paulo Alcantara (SUSE) 
  Paulo Alcantara 
  Sean Christopherson 
  Steve French 
  Takashi Sakamoto 
  Timothy Pearson 
  wuqiang.matt 
  Yang Yingliang 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt 

[linux-linus test] 183980: regressions - FAIL

[osstest service owner]

flight 183980 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183980/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  6 kernel-build fail REGR. vs. 183973

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 183973
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183973
 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 183973
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 183973
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 183973
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 183973
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 183973
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 183973
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-vhd  14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass

version targeted for testing:
 linux968f35f4ab1c0966ceb39af3c89f2e24afedf878
baseline version:
 linux815fb87b753055df2d9e50f6cd80eb10235fe3e9

Last test of basis   183973  2023-12-02 07:48:26 Z1 days
Failing since183977  2023-12-03 00:12:06 Z0 days2 attempts
Testing same since   183980  2023-12-03 08:00:05 Z0 days1 attempts


People who touched revisions under test:
  Alex Williamson 
  Brett Creeley 
  Dan Carpenter 
  David Howells 
  Dmitry Antipov 
  Jens Axboe 
  JP Kobryn 
  Juergen Gross 
  Linus Torvalds 
  Masami Hiramatsu (Google) 
  Michael Ellerman 
  Namjae Jeon 
  Nicholas Piggin 
  Paulo Alcantara (SUSE) 
  Paulo Alcantara 
  Sean Christopherson 
  Steve French 
  Takashi Sakamoto 
  Timothy Pearson 
  wuqiang.matt 
  Yang Yingliang 

jobs:
 build-amd64-xsm  pass
 

[BUG]i2c_hid_acpi broken with 4.17.2 on Framework Laptop 13 AMD

[Sébastien Chaumat]

Hello,

 Trying to get the Framework Laptop 13 AMD to work with QubesOS I hit the
following Xen issue :

Xen version : 4.17.2
Kernel : 6.5.12-300.fc39.x86_64
CPU  model name : AMD Ryzen 7 7840U w/ Radeon  780M Graphics

The touchpad is not working (not detected by evtest) because ( see below
for XXX values) :
[   10.215870] i2c_hid_acpi i2c-FRMXXX: failed to reset device: -61

which is maybe related to the previous messages :

[2.065750] [Firmware Bug]: ACPI MWAIT C-state 0x0 not supported by HW
(0x0)
...
[2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt

QubesOS issue : https://github.com/QubesOS/qubes-issues/issues/8734

Possibly related issues :

 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1971597

Here's the complete diff of dmesg with and without xen loaded up to the
failed i2c_hid_acpi init :

[0.00] Command line: placeholder
root=UUID=71b1dc59-ea00-484c-b5e4-ee77ede771db ro rhgb quiet
[0.00] Released 0 page(s)
[0.00] NX (Execute Disable) protection: active
[0.00] efi: ACPI=0x5affe000 ACPI 2.0=0x5affe014
TPMFinalLog=0x5af3f000 SMBIOS=0x51677000 SMBIOS 3.0=0x51674000
(MEMATTR=0x4b719018 unusable) ESRT=0x5af9b018 MOKvar=0x5187c000
[0.00] Hypervisor detected: Xen PV
[0.026644] tsc: Detected 3294.105 MHz processor
[0.026645] tsc: Detected 3293.856 MHz TSC
[0.026732] MTRR map: 3 entries (0 fixed + 3 variable; max 16), built
from 8 variable MTRRs
[0.026733] MTRRs set to read-only
[0.026735] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WC  WP  UC  UC

[0.026753] esrt: Reserving ESRT space from 0x5af9b018 to
0x5af9b050.
[1.042047] ACPI: BGRT 0x5AFB8000 38 (v01 INSYDE EDK2
0002 ACPI 0004)
[1.042095] Setting APIC routing to Xen PV.
[1.042116] NUMA turned off
[1.101730] On node 0, zone DMA: 128 pages in unavailable ranges
[1.136828] p2m virtual area at (ptrval), size is 4000
[1.401457] Remapped 728641 page(s)
[1.402499] Booting kernel on Xen
[1.402500] Xen version: 4.17.2 (preserve-AD)
[1.406607] xen: PV spinlocks enabled
[1.406609] PV qspinlock hash table entries: 256 (order: 0, 4096 bytes,
linear)
[1.406610] Kernel command line: placeholder
root=UUID=71b1dc59-ea00-484c-b5e4-ee77ede771db ro rhgb quiet
[1.406661] Unknown kernel command line parameters "placeholder rhgb",
will be passed to user space.
[1.406867] random: crng init done
[1.411447] Built 1 zonelists, mobility grouping on.  Total pages:
15403418
[1.497107] Memory: 60184272K/62591736K available (18432K kernel code,
3267K rwdata, 14476K rodata, 4532K init, 17364K bss, 2407212K reserved, 0K
cma-reserved)
[1.508627] xen:events: Using FIFO-based ABI
[1.508634] xen: --> pirq=1 -> irq=1 (gsi=1)
[1.508636] xen: --> pirq=2 -> irq=2 (gsi=2)
[1.508638] xen: --> pirq=3 -> irq=3 (gsi=3)
[1.508639] xen: --> pirq=4 -> irq=4 (gsi=4)
[1.508640] xen: --> pirq=5 -> irq=5 (gsi=5)
[1.508642] xen: --> pirq=6 -> irq=6 (gsi=6)
[1.508643] xen: --> pirq=7 -> irq=7 (gsi=7)
[1.508644] xen: --> pirq=8 -> irq=8 (gsi=8)
[1.508646] xen: --> pirq=9 -> irq=9 (gsi=9)
[1.508647] xen: --> pirq=10 -> irq=10 (gsi=10)
[1.508649] xen: --> pirq=11 -> irq=11 (gsi=11)
[1.508650] xen: --> pirq=12 -> irq=12 (gsi=12)
[1.508652] xen: --> pirq=13 -> irq=13 (gsi=13)
[1.508653] xen: --> pirq=14 -> irq=14 (gsi=14)
[1.508654] xen: --> pirq=15 -> irq=15 (gsi=15)
[1.508913] printk: console [hvc0] enabled
[1.543395] ACPI BIOS Warning (bug): Incorrect checksum in table [BGRT]
- 0xC1, should be 0x4C (20230331/utcksum-58)
[1.543432] clocksource: xen: mask: 0x max_cycles:
0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[1.543434] Xen: using vcpuop timer interface
[1.543436] installing Xen timer for CPU 0
[1.543449] clocksource: tsc-early: mask: 0x max_cycles:
0x2f7aa0787ee, max_idle_ns: 440795321263 ns
[1.543452] Calibrating delay loop (skipped), value calculated using
timer frequency.. 6587.71 BogoMIPS (lpj=3293856)
[1.543485] Spectre V2 : Mitigation: Retpolines
[1.543487] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT
[1.543489] Speculative Store Bypass: Vulnerable
[1.543505] x86/fpu: Enabled xstate features 0xe7, context size is 2432
bytes, using 'compacted' format.
[1.556516] cpu 0 spinlock event irq 57
[1.556526] VPMU disabled by hypervisor.
[1.556812] Performance Events: PMU not available due to virtualization,
using software events only.
[1.559433] NMI watchdog: Perf NMI watchdog permanently disabled
[1.559727] installing Xen timer for CPU 1
[1.559965] installing Xen timer for CPU 2
[1.560180] installing Xen timer for CPU 3
[1.560396] installing Xen timer for CPU 4
[1.560599] installing Xen timer for CPU 5
[1.560813] installing Xen timer for CPU 6
[1.561021] installing Xen timer for CPU 7
[

[xen-unstable test] 183978: tolerable FAIL

[osstest service owner]

flight 183978 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183978/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw 12 debian-di-install fail in 183974 pass in 183978
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 
183974
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 20 guest-start/debianhvm.repeat 
fail pass in 183974

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail  like 183971
 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183974
 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 183974
 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 183974
 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 183974
 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 183974
 test-armhf-armhf-libvirt 16 saverestore-support-checkfail  like 183974
 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 183974
 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check   fail like 183974
 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 183974
 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 183974
 test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install   fail like 183974
 test-amd64-i386-libvirt-xsm  15 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  15 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim14 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  16 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  16 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit1  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 15 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  14 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-vhd  15 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  15 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  16 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 15 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass
 test-armhf-armhf-xl-vhd  14 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  15 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  525c7c094b258e8a46b494488eef96f5670eb352
baseline version:
 xen  

[ovmf test] 183979: all pass - PUSHED

[osstest service owner]

flight 183979 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183979/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 3e133f730b69a2b5a5cb875ed27e0439053663c4
baseline version:
 ovmf 70b174e24db4a6de1590fda65846074dcb9fd7d3

Last test of basis   183966  2023-12-01 15:11:04 Z1 days
Testing same since   183979  2023-12-03 02:41:27 Z0 days1 attempts


People who touched revisions under test:
  Pedro Falcato 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   70b174e24d..3e133f730b  3e133f730b69a2b5a5cb875ed27e0439053663c4 -> 
xen-tested-master