[linux-5.4 test] 170846: regressions - FAIL
flight 170846 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/170846/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-examine-uefi 6 xen-install fail REGR. vs. 170736 test-armhf-armhf-xl-credit1 14 guest-start fail REGR. vs. 170736 build-amd64 6 xen-build fail in 170843 REGR. vs. 170736 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-credit2 14 guest-start fail in 170843 pass in 170846 test-armhf-armhf-xl-multivcpu 14 guest-start fail pass in 170843 test-armhf-armhf-xl-arndale 18 guest-start/debian.repeat fail pass in 170843 test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeat fail pass in 170843 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-examine 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 170843 n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked in 170843 n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked in 170843 n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1)blocked in 170843 n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked in 170843 n/a test-amd64-i386-examine-bios 1 build-check(1) blocked in 170843 n/a test-amd64-i386-freebsd10-amd64 1 build-check(1)blocked in 170843 n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1)blocked in 170843 n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-pair 1 build-check(1) blocked in 170843 n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-examine-uefi 1 build-check(1) blocked in 170843 n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1)blocked in 170843 n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked in 170843 n/a test-amd64-i386-examine 1 build-check(1) blocked in 170843 n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked in 170843 n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked in 170843 n/a test-amd64-i386-xl-vhd1 build-check(1) blocked in 170843 n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked in 170843 n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-examine-bios 1 build-check(1) blocked in 170843 n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1)blocked in 170843 n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked in 170843 n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1)blocked in 170843 n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked in 170843 n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1)blocked in 170843 n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked in 170843 n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-pygrub 1 build-check(1) blocked in 170843 n/a test-amd64-i386-pair 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 170843 n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked in 170843 n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1)blocked in 170843 n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked in 170843 n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked in 170843 n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked in 170843 n/a test-amd64-i386-xl1 build-check(1) blocked in 170843 n/a test-amd64-amd64-xl 1 build-check(1) blocked
[PATCH Resend] xen/netback: do some code cleanup
Remove some unused macros and functions, make local functions static.
Signed-off-by: Juergen Gross
Acked-by: Wei Liu
---
drivers/net/xen-netback/common.h| 12
drivers/net/xen-netback/interface.c | 16 +---
drivers/net/xen-netback/netback.c | 4 +++-
drivers/net/xen-netback/rx.c| 2 +-
4 files changed, 5 insertions(+), 29 deletions(-)
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index d9dea4829c86..8174d7b2966c 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -48,7 +48,6 @@
#include
typedef unsigned int pending_ring_idx_t;
-#define INVALID_PENDING_RING_IDX (~0U)
struct pending_tx_info {
struct xen_netif_tx_request req; /* tx request */
@@ -82,8 +81,6 @@ struct xenvif_rx_meta {
/* Discriminate from any valid pending_idx value. */
#define INVALID_PENDING_IDX 0x
-#define MAX_BUFFER_OFFSET XEN_PAGE_SIZE
-
#define MAX_PENDING_REQS XEN_NETIF_TX_RING_SIZE
/* The maximum number of frags is derived from the size of a grant (same
@@ -367,11 +364,6 @@ void xenvif_free(struct xenvif *vif);
int xenvif_xenbus_init(void);
void xenvif_xenbus_fini(void);
-int xenvif_schedulable(struct xenvif *vif);
-
-int xenvif_queue_stopped(struct xenvif_queue *queue);
-void xenvif_wake_queue(struct xenvif_queue *queue);
-
/* (Un)Map communication rings. */
void xenvif_unmap_frontend_data_rings(struct xenvif_queue *queue);
int xenvif_map_frontend_data_rings(struct xenvif_queue *queue,
@@ -394,7 +386,6 @@ int xenvif_dealloc_kthread(void *data);
irqreturn_t xenvif_ctrl_irq_fn(int irq, void *data);
bool xenvif_have_rx_work(struct xenvif_queue *queue, bool test_kthread);
-void xenvif_rx_action(struct xenvif_queue *queue);
void xenvif_rx_queue_tail(struct xenvif_queue *queue, struct sk_buff *skb);
void xenvif_carrier_on(struct xenvif *vif);
@@ -403,9 +394,6 @@ void xenvif_carrier_on(struct xenvif *vif);
void xenvif_zerocopy_callback(struct sk_buff *skb, struct ubuf_info *ubuf,
bool zerocopy_success);
-/* Unmap a pending page and release it back to the guest */
-void xenvif_idx_unmap(struct xenvif_queue *queue, u16 pending_idx);
-
static inline pending_ring_idx_t nr_pending_reqs(struct xenvif_queue *queue)
{
return MAX_PENDING_REQS -
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index 8e035374a370..fb32ae82d9b0 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -69,7 +69,7 @@ void xenvif_skb_zerocopy_complete(struct xenvif_queue *queue)
wake_up(>dealloc_wq);
}
-int xenvif_schedulable(struct xenvif *vif)
+static int xenvif_schedulable(struct xenvif *vif)
{
return netif_running(vif->dev) &&
test_bit(VIF_STATUS_CONNECTED, >status) &&
@@ -177,20 +177,6 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
}
-int xenvif_queue_stopped(struct xenvif_queue *queue)
-{
- struct net_device *dev = queue->vif->dev;
- unsigned int id = queue->id;
- return netif_tx_queue_stopped(netdev_get_tx_queue(dev, id));
-}
-
-void xenvif_wake_queue(struct xenvif_queue *queue)
-{
- struct net_device *dev = queue->vif->dev;
- unsigned int id = queue->id;
- netif_tx_wake_queue(netdev_get_tx_queue(dev, id));
-}
-
static u16 xenvif_select_queue(struct net_device *dev, struct sk_buff *skb,
struct net_device *sb_dev)
{
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index d93814c14a23..fc61a4418737 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -112,6 +112,8 @@ static void make_tx_response(struct xenvif_queue *queue,
s8 st);
static void push_tx_responses(struct xenvif_queue *queue);
+static void xenvif_idx_unmap(struct xenvif_queue *queue, u16 pending_idx);
+
static inline int tx_work_todo(struct xenvif_queue *queue);
static inline unsigned long idx_to_pfn(struct xenvif_queue *queue,
@@ -1418,7 +1420,7 @@ static void push_tx_responses(struct xenvif_queue *queue)
notify_remote_via_irq(queue->tx_irq);
}
-void xenvif_idx_unmap(struct xenvif_queue *queue, u16 pending_idx)
+static void xenvif_idx_unmap(struct xenvif_queue *queue, u16 pending_idx)
{
int ret;
struct gnttab_unmap_grant_ref tx_unmap_op;
diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index dbac4c03d21a..8df2c736fd23 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -486,7 +486,7 @@ static void xenvif_rx_skb(struct xenvif_queue *queue)
#define RX_BATCH_SIZE 64
-void xenvif_rx_action(struct xenvif_queue *queue)
+static void xenvif_rx_action(struct xenvif_queue *queue)
{
struct sk_buff_head completed_skbs;
unsigned int work_done = 0;
--
2.35.3
OpenPGP_0xB0DE9DD628BF132F.asc
Re: [PATCH v6 0/9] xen: drop hypercall function tables
On 18.05.22 11:45, Juergen Gross wrote: On 04.05.22 09:53, Juergen Gross wrote: On 19.04.22 10:01, Juergen Gross wrote: On 24.03.22 15:01, Juergen Gross wrote: In order to avoid indirect function calls on the hypercall path as much as possible this series is removing the hypercall function tables and is replacing the hypercall handler calls via the function array by automatically generated call macros. Another by-product of generating the call macros is the automatic generating of the hypercall handler prototypes from the same data base which is used to generate the macros. This has the additional advantage of using type safe calls of the handlers and to ensure related handler (e.g. PV and HVM ones) share the same prototypes. A very brief performance test (parallel build of the Xen hypervisor in a 6 vcpu guest) showed a very slim improvement (less than 1%) of the performance with the patches applied. The test was performed using a PV and a PVH guest. A gentle ping regarding this series. I think patch 1 still lacks an Ack from x86 side. Other than that patches 1, 2 and 4 should be fine to go in, as they are cleanups which are fine on their own IMHO. Andrew, you wanted to get some performance numbers of the series using the Citrix test environment. Any news on the progress here? And another ping. Andrew, could you please give some feedback regarding performance testing progress? This is becoming ridiculous. Andrew, I know you are busy, but not reacting at all to explicit questions is kind of annoying. ___ _ _ | _ \_ _| \ | |/ ___| | |_) | || \| | | _ | __/| || |\ | |_| | |_| |___|_| \_|\| Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v6 1/9] xen: move do_vcpu_op() to arch specific code
On 24.03.22 15:01, Juergen Gross wrote:
The entry point used for the vcpu_op hypercall on Arm is different
from the one on x86 today, as some of the common sub-ops are not
supported on Arm. The Arm specific handler filters out the not
supported sub-ops and then calls the common handler. This leads to the
weird call hierarchy:
do_arm_vcpu_op()
do_vcpu_op()
arch_do_vcpu_op()
Clean this up by renaming do_vcpu_op() to common_vcpu_op() and
arch_do_vcpu_op() in each architecture to do_vcpu_op(). This way one
of above calls can be avoided without restricting any potential
future use of common sub-ops for Arm.
Signed-off-by: Juergen Gross
Reviewed-by: Julien Grall
There is still an Ack missing for x86 side. Jan already said he isn't
happy to give one, but won't Nack it. Roger, Andrew, any comments for
this patch? It is blocking further cleanup patches to go in (patches
2 and 4 of this series).
Juergen
---
V4:
- don't remove HYPERCALL_ARM()
V4.1:
- add missing cf_check (Andrew Cooper)
V5:
- use v instead of current (Julien Grall)
---
xen/arch/arm/domain.c| 15 ---
xen/arch/arm/include/asm/hypercall.h | 2 --
xen/arch/arm/traps.c | 2 +-
xen/arch/x86/domain.c| 12
xen/arch/x86/include/asm/hypercall.h | 2 +-
xen/arch/x86/x86_64/domain.c | 18 +-
xen/common/compat/domain.c | 15 ++-
xen/common/domain.c | 12
xen/include/xen/hypercall.h | 2 +-
9 files changed, 42 insertions(+), 38 deletions(-)
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 8110c1df86..2f8eaab7b5 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -1079,23 +1079,24 @@ void arch_dump_domain_info(struct domain *d)
}
-long do_arm_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
+long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
{
+struct domain *d = current->domain;
+struct vcpu *v;
+
+if ( (v = domain_vcpu(d, vcpuid)) == NULL )
+return -ENOENT;
+
switch ( cmd )
{
case VCPUOP_register_vcpu_info:
case VCPUOP_register_runstate_memory_area:
-return do_vcpu_op(cmd, vcpuid, arg);
+return common_vcpu_op(cmd, v, arg);
default:
return -EINVAL;
}
}
-long arch_do_vcpu_op(int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
-{
-return -ENOSYS;
-}
-
void arch_dump_vcpu_info(struct vcpu *v)
{
gic_dump_info(v);
diff --git a/xen/arch/arm/include/asm/hypercall.h
b/xen/arch/arm/include/asm/hypercall.h
index 39d2e7889d..fac4d60f17 100644
--- a/xen/arch/arm/include/asm/hypercall.h
+++ b/xen/arch/arm/include/asm/hypercall.h
@@ -4,8 +4,6 @@
#include /* for arch_do_domctl */
int do_arm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg);
-long do_arm_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg);
-
long subarch_do_domctl(struct xen_domctl *domctl, struct domain *d,
XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 43f30747cf..e906bb4a89 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1380,7 +1380,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
#endif
HYPERCALL(multicall, 2),
HYPERCALL(platform_op, 1),
-HYPERCALL_ARM(vcpu_op, 3),
+HYPERCALL(vcpu_op, 3),
HYPERCALL(vm_assist, 2),
#ifdef CONFIG_ARGO
HYPERCALL(argo_op, 5),
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index a5048ed654..d566fc82b4 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1489,11 +1489,15 @@ int arch_vcpu_reset(struct vcpu *v)
return 0;
}
-long
-arch_do_vcpu_op(
-int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg)
+long cf_check do_vcpu_op(int cmd, unsigned int vcpuid,
+ XEN_GUEST_HANDLE_PARAM(void) arg)
{
long rc = 0;
+struct domain *d = current->domain;
+struct vcpu *v;
+
+if ( (v = domain_vcpu(d, vcpuid)) == NULL )
+return -ENOENT;
switch ( cmd )
{
@@ -1545,7 +1549,7 @@ arch_do_vcpu_op(
}
default:
-rc = -ENOSYS;
+rc = common_vcpu_op(cmd, v, arg);
break;
}
diff --git a/xen/arch/x86/include/asm/hypercall.h b/xen/arch/x86/include/asm/hypercall.h
index 61bf897147..d6daa7e4cb 100644
--- a/xen/arch/x86/include/asm/hypercall.h
+++ b/xen/arch/x86/include/asm/hypercall.h
@@ -145,7 +145,7 @@ compat_physdev_op(
XEN_GUEST_HANDLE_PARAM(void) arg);
extern int
-arch_compat_vcpu_op(
+compat_common_vcpu_op(
int cmd, struct vcpu *v, XEN_GUEST_HANDLE_PARAM(void) arg);
extern int cf_check compat_mmuext_op(
diff --git a/xen/arch/x86/x86_64/domain.c b/xen/arch/x86/x86_64/domain.c
index c46dccc25a..9c559aa3ea 100644
---
memory overcomittment with sr-iov device assighment
Hello list, I looked into Xen documentation and also Xen wiki and I could't find a definitive answer if Xen supports memory over-commitment when VMs use SR-IOV device assignment (passthrough). Memory over-commitment I mean giving VMs more RAM than is available in the host. I know that ESX doesn't support it, and also QEMU/KVM pins all RAM when a device is directly assigned to a VM (VFIO_IOMMU_MAP_DMA ioctl). I have two questions: 1. Does Xen supports memory over commitment when all VMs are using direct device assignment e.g., SR-IOV? 2. Would you please point me to the code that does the pinning? Thanks, Alex
[qemu-mainline test] 170849: tolerable FAIL - PUSHED
flight 170849 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/170849/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-vhd 21 guest-start/debian.repeatfail like 170824 test-armhf-armhf-xl-rtds 14 guest-start fail like 170829 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170836 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170836 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170836 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 170836 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170836 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170836 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 170836 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170836 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-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-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-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-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-raw 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-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-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 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-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 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-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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 test-armhf-armhf-libvirt-raw 14 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 version targeted for testing: qemuu57c9363c452af64fe058aa946cc923eae7f7ad33 baseline version: qemuuca127b3fc247517ec7d4dad291f2c0f90602ce5b Last test of basis 170836 2022-06-05 04:31:21 Z1 days Testing same since 170849 2022-06-06 17:39:05 Z0 days1 attempts People who touched revisions under test: Dario Faggioli Igor Mammedov John Snow
[ovmf test] 170855: all pass - PUSHED
flight 170855 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170855/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 4f89e4b3e80329b9a44559c658d2ebce8475 baseline version: ovmf 0b36dea3f8b71c4fdf3a5d2edf395115568b Last test of basis 170839 2022-06-06 00:11:39 Z1 days Testing same since 170855 2022-06-07 01:57:37 Z0 days1 attempts People who touched revisions under test: Kun Qin 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 0b36dea3f8..4f89e4b3e8 4f89e4b3e80329b9a44559c658d2ebce8475 -> xen-tested-master
Re: MOVING COMMUNITY CALL Call for agenda items for 9 June Community Call @ 1500 UTC
On Thu, 2 Jun 2022, Jan Beulich wrote:
> On 01.06.2022 22:27, Stefano Stabellini wrote:
> > Reducing CC and adding fusa-sig
> >
> > Actually Jun 9 at 8AM California / 4PM UK doesn't work for some of you,
> > so it is either:
> > 1) Jun 9 at 7AM California / 3PM UK
> > 2) Jun 14 at 8AM California / 4PM UK
> >
> > My preference is the first option because it is sooner but let me know
> > if it doesn't work and we'll try the second option.
>
> I don't think I was aware that another call is needed. Was that said
> somewhere earlier where I did miss it? In any event, either option
> looks to be okay here.
I sent out the meeting invite for Jun 9 at 7AM California / 3PM UK.
Just a reminder to fill in the remaining "yellow" rules of the
spreadsheet in advance of the meeting.
There are couple of interesting questions on the remaining rules, which
I tried to shed some light on.
# Rule 9.1 "The value of an object with automatic storage duration shall not be
read before it has been set"
The question is whether -Wuninitalised already covers this case or not.
I think it does.
Eclair is reporting a few issues where variables are "possibly
uninitialized". We should ask Roberto about them, I don't think they are
actual errors? More like extra warnings?
# Rule 9.3 "Arrays shall not be partially initialized"
Andrew was pointing out that "we use implicit 0's all over the place".
That is true but as far as I can tell that is permitted. There is a
couple of exceptions to the rules:
- { 0 } is allowed
- sparse initialization using designated initializers is allowed
e.g. char ar[3] = { [2] = 'c' }
So I think we are fine there.
# Rule 9.4 "An element of an object shall not be initialized more than once"
Andrew was noting that "There's one pattern using range syntax to set a
default where this rule would be violated, but the code is far cleaner
to read."
Range initializers is a GCC extension not part of the C standard. It is
not considered by the MISRA rule. The MISRA rule seems focused on
preveting accidental double-initializations (by copy/pasting errors for
instance) which is fair.
So I think we should be OK here and we need to clarify our usage of
range initializers. What we do or don't do with range initializer should
be a separate discussion I think.
Re: [PATCH v2 0/2] introduce docs/misra/rules.rst
On Tue, 31 May 2022, Stefano Stabellini wrote: > Hi all, > > This patch series is a follow-up from the MISRA C meeting last Thursday, > when we went through the list of MISRA C rules on the spreadsheet and > agreed to accept into the Xen coding style the first ones, starting from > Dir 2.1 up until Rule 5.1 (except for Rule 2.2) in descending popularity > order. > > This is the full list of accepted rules so far: > > Dir 2.1 > Dir 4.7 > Dir 4.10 > Dir 4.14 > Rule 1.3 > Rule 3.2 > Rule 5.1 > Rule 6.2 > Rule 8.1 > Rule 8.4 > Rule 8.5 > Rule 8.6 > Rule 8.8 > Rule 8.12 > > This short patch series add them as a new document under docs/misra as a > list in rst format. The file can be used as input to cppcheck using a > small python script from Bertrand (who will send it to the xen-devel > separately.) The two patches are acked and I plan to commit them in a day or two.
Re: [PATCH v2 3/4] arm: add ISAR2, MMFR0 and MMFR1 fields in cpufeature
On Mon, 6 Jun 2022, Bertrand Marquis wrote:
> Hi Stefano,
>
> > On 3 Jun 2022, at 02:45, Stefano Stabellini wrote:
> >
> > On Tue, 31 May 2022, Bertrand Marquis wrote:
> >> Complete AA64ISAR2 and AA64MMFR[0-1] with more fields.
> >> While there add a comment for MMFR bitfields as for other registers in
> >> the cpuinfo structure definition.
> >>
> >> Signed-off-by: Bertrand Marquis
> >> ---
> >> Changes in v2:
> >> - patch introduced to isolate changes in cpufeature.h
> >> - complete MMFR0 and ISAR2 to sync with sysregs.h status
> >> ---
> >> xen/arch/arm/include/asm/cpufeature.h | 28 ++-
> >> 1 file changed, 23 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/xen/arch/arm/include/asm/cpufeature.h
> >> b/xen/arch/arm/include/asm/cpufeature.h
> >> index 9649a7afee..57eb6773d3 100644
> >> --- a/xen/arch/arm/include/asm/cpufeature.h
> >> +++ b/xen/arch/arm/include/asm/cpufeature.h
> >> @@ -234,6 +234,7 @@ struct cpuinfo_arm {
> >> union {
> >> register_t bits[3];
> >> struct {
> >> + /* MMFR0 */
> >> unsigned long pa_range:4;
> >> unsigned long asid_bits:4;
> >> unsigned long bigend:4;
> >> @@ -242,18 +243,31 @@ struct cpuinfo_arm {
> >> unsigned long tgranule_16K:4;
> >> unsigned long tgranule_64K:4;
> >> unsigned long tgranule_4K:4;
> >> - unsigned long __res0:32;
> >> -
> >> + unsigned long tgranule_16k_2:4;
> >> + unsigned long tgranule_64k_2:4;
> >> + unsigned long tgranule_4k:4;
> >
> > Should be tgranule_4k_2:4
>
> Right I will fix that.
>
> >
> >
> >> + unsigned long exs:4;
> >> + unsigned long __res0:8;
> >> + unsigned long fgt:4;
> >> + unsigned long ecv:4;
> >> +
> >> + /* MMFR1 */
> >> unsigned long hafdbs:4;
> >> unsigned long vmid_bits:4;
> >> unsigned long vh:4;
> >> unsigned long hpds:4;
> >> unsigned long lo:4;
> >> unsigned long pan:4;
> >> - unsigned long __res1:8;
> >> - unsigned long __res2:28;
> >> + unsigned long specsei:4;
> >> + unsigned long xnx:4;
> >> + unsigned long twed:4;
> >> + unsigned long ets:4;
> >> + unsigned long __res1:4;
> >
> > hcx?
> >
> >
> >> + unsigned long afp:4;
> >> + unsigned long __res2:12;
> >
> > ntlbpa
> > tidcp1
> > cmow
> >
> >> unsigned long ecbhb:4;
> >
> > Strangely enough I am looking at DDI0487H and ecbhb is not there
> > (D13.2.65). Am I looking at the wrong location?
>
> Right now I declared here only the values which have a corresponding
> declaration in sysregs.h
> If I add more fields here we will not be in sync with it anymore.
>
> And on ecbhb it will be in the next revision of the manual yes.
>
>
> >
> >
> >> + /* MMFR2 */
> >> unsigned long __res3:64;
> >> };
> >> } mm64;
> >> @@ -297,7 +311,11 @@ struct cpuinfo_arm {
> >> unsigned long __res2:8;
> >>
> >> /* ISAR2 */
> >> - unsigned long __res3:28;
> >> + unsigned long wfxt:4;
> >> + unsigned long rpres:4;
> >> + unsigned long gpa3:4;
> >> + unsigned long apa3:4;
> >> + unsigned long __res3:12;
> >
> > mops
> > bc
> > pac_frac
> >
> >
> >> unsigned long clearbhb:4;
> >
> > And again this is not described at D13.2.63. Probably the bhb stuff
> > didn't make it into the ARM ARM yet.
>
> As said before, are you ok with only adding stuff declared in sysregs
> to make it simpler to sync with Linux ?
Yes, that makes sense. In that case just fix tgranule_4k_2 and you can
add my
Reviewed-by: Stefano Stabellini
Re: [PATCH] xen: unexport __init-annotated xen_xlate_map_ballooned_pages()
On Mon, 6 Jun 2022, Oleksandr wrote:
> On 06.06.22 07:59, Masahiro Yamada wrote:
>
> Hello
>
> > EXPORT_SYMBOL and __init is a bad combination because the .init.text
> > section is freed up after the initialization. Hence, modules cannot
> > use symbols annotated __init. The access to a freed symbol may end up
> > with kernel panic.
> >
> > modpost used to detect it, but it has been broken for a decade.
> >
> > Recently, I fixed modpost so it started to warn it again, then this
> > showed up in linux-next builds.
> >
> > There are two ways to fix it:
> >
> >- Remove __init
> >- Remove EXPORT_SYMBOL
> >
> > I chose the latter for this case because none of the in-tree call-sites
> > (arch/arm/xen/enlighten.c, arch/x86/xen/grant-table.c) is compiled as
> > modular.
>
> Good description.
>
>
> >
> > Fixes: 243848fc018c ("xen/grant-table: Move xlated_setup_gnttab_pages to
> > common place")
> > Reported-by: Stephen Rothwell
> > Signed-off-by: Masahiro Yamada
>
> I think the patch is correct.
>
> Reviewed-by: Oleksandr Tyshchenko
Acked-by: Stefano Stabellini
> > ---
> >
> > drivers/xen/xlate_mmu.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> > index 34742c6e189e..f17c4c03db30 100644
> > --- a/drivers/xen/xlate_mmu.c
> > +++ b/drivers/xen/xlate_mmu.c
> > @@ -261,7 +261,6 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t
> > **gfns, void **virt,
> > return 0;
> > }
> > -EXPORT_SYMBOL_GPL(xen_xlate_map_ballooned_pages);
> > struct remap_pfn {
> > struct mm_struct *mm;
>
> --
> Regards,
>
> Oleksandr Tyshchenko
>
[xen-unstable-smoke test] 170850: tolerable all pass - PUSHED
flight 170850 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/170850/ 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 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 version targeted for testing: xen cea9ae06229577cd5b77019ce122f9cdd1568106 baseline version: xen 58ce5b6c33ecae76f2e9fc5213a56e98c3be4be5 Last test of basis 170796 2022-06-01 08:00:24 Z5 days Testing same since 170850 2022-06-06 18:00:31 Z0 days1 attempts People who touched revisions under test: Andrew Cooper jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt 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/xen.git 58ce5b6c33..cea9ae0622 cea9ae06229577cd5b77019ce122f9cdd1568106 -> smoke
[linux-linus test] 170844: regressions - FAIL
flight 170844 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/170844/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-xl-pvhv2-intel 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-qemuu-nested-intel 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-pair 12 xen-boot/src_host fail REGR. vs. 170714 test-amd64-amd64-libvirt-pair 13 xen-boot/dst_host fail REGR. vs. 170714 test-amd64-amd64-freebsd12-amd64 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-qcow2 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-raw 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-examine 8 reboot fail REGR. vs. 170714 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-libvirt-raw 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-examine-bios 8 reboot fail REGR. vs. 170714 test-amd64-amd64-examine-uefi 8 reboot fail REGR. vs. 170714 test-amd64-amd64-examine 8 reboot fail REGR. vs. 170714 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 170714 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170714 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170714 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170714 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 170714 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170714 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170714 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170714 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170714 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-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-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 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-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-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-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 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: linuxf2906aa863381afb0015a9eb7fefad885d4e5a56 baseline version: linuxd6ecaa0024485effd065124fe774de2e22095f2d Last test of basis 170714 2022-05-24 03:27:44 Z 13 days Failing since170716 2022-05-24 11:12:06 Z 13 days 38 attempts Testing same since 170841 2022-06-06 03:15:23 Z0 days2 attempts 2274 people touched revisions under test, not listing them all jobs: build-amd64-xsm
Re: [XEN PATCH] tools/libs/light/libxl_pci.c: explicitly grant access to Intel IGD opregion
On 6/3/22 9:10 PM, Chuck Zmudzinski wrote:
On 3/30/22 1:15 PM, Anthony PERARD wrote:
Hi Chuck,
On Sun, Mar 13, 2022 at 11:41:37PM -0400, Chuck Zmudzinski wrote:
When gfx_passthru is enabled for the Intel IGD, hvmloader maps the IGD
opregion to the guest but libxl does not grant the guest permission to
I'm not reading the same thing when looking at code in hvmloader. It
seems that hvmloader allocate some memory for the IGD opregion rather
than mapping it.
tools/firmware/hvmloader/pci.c:184
if ( vendor_id == 0x8086 )
{
igd_opregion_pgbase = mem_hole_alloc(IGD_OPREGION_PAGES);
/*
* Write the the OpRegion offset to give the opregion
* address to the device model. The device model will trap
* and map the OpRegion at the give address.
*/
pci_writel(vga_devfn, PCI_INTEL_OPREGION,
igd_opregion_pgbase << PAGE_SHIFT);
}
I think this write would go through QEMU, does it do something with it?
(I kind of replying to this question at the end of the mail.)
Is this code in hvmloader actually run in your case?
Currently, because of another bug in Qemu upstream, this crash can
only be reproduced using the traditional Qemu device model, and of
qemu-traditional is a bit old... What is the bug in QEMU? Do you have a
link to a patch/mail?
I finally found a patch that fixes the upstream bug on my system
but I am not sure it is the best fix. It is a patch that QubesOS has
been using since 2017.
I just opened an issue titled "Incorrect register mask for PCI
passthrough on Xen" with Qemu upstream about this problem
which gives all the details:
https://gitlab.com/qemu-project/qemu/-/issues/1061
When you get a chance, can you take a look at it?
Not being an official Xen or Qemu developer, I would appreciate
any suggestions you might have for me before I formally submit
a patch to Qemu upstream. Please reply here or on the Qemu issue
tracker.
Best Regards,
Chuck
I finally found a patch for the other bug in Qemu upstream. The
patch is currently being used in QubesOS, and they first added
it to their version of Qemu way back in 2017:
https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/pull/3/commits/ab2b4c2ad02827a73c52ba561e9a921cc4bb227c
Although this patch is advertised as applying to the device model
running in a Linux stub domain, it is also needed (at least on my
system) with the device model running in Dom0.
Here is the story:
The patch is titled "qemu: fix wrong mask in pci capability registers
handling"
There is scant information in the commit message about the nature of
the problem, but I discovered the following in my testing:
On my Intel Haswell system configured for PCI passthrough to the
Xen HVM guest, Qemu does indeed incorrectly set the emulated
register because it uses the wrong mask that disables instead of
enables the PCI_STATUS_CAP_LIST bit of the PCI_STATUS register.
This disabled the MSI-x capability of two of the three PCI devices
passed through to the Xen HVM guest. The problem only
manifests in a bad way in a Linux guest, not in a Windows guest.
One possible reason that only Linux guests are affected is that
I discovered in the Xen xl-dmesg verbose logs that Windows and
Linux use different callbacks for interrupts:
(XEN) Dom1 callback via changed to GSI 28
...
(XEN) Dom3 callback via changed to Direct Vector 0xf3
Dom1 is a Windows Xen HVM and Dom3 is a Linux HVM
Apparently the Direct Vector callback that Linux uses requires
MSI or MSI-x capability of the passed through devices, but the
wrong mask in Qemu disables that capability.
After applying the QubesOS patch to Qemu upstream, the
PCI_STATUS_CAP_LIST bit is set correctly for the guest and
PCI and Intel IGD passthrough works normally because the
Linux guest can make use of the MSI-x capability of the
PCI devices.
The problem was discovered almost five years ago. I don't
know why the fix has not been committed to Qemu
upstream yet.
After this, I was able to discover that the need for libxl to
explicitly grant permission for access to the Intel OpRegion
is only needed for the old traditional device model because
the Xen hypercall to gain permission is included in upstream
Qemu, but it is omitted from the old traditional device model.
So this patch is not needed for users of the upstream device
model who also add the QubesOS patch to fix the
PCI_STATUS_CAP_LIST bit in the PCI_STATUS register.
This all assumes the device model is running in Dom0. The
permission for access to the Intel OpRegion might still be
needed if the upstream device model is running in a stub
domain.
There are other problems in addition to this problem of access
to the Intel OpRegion that are discussed here:
https://www.qubes-os.org/news/2017/10/18/msi-support/
As old as that post is, the feature of allowing PCI and VGA
passthrough to HVM domains is still not well supported,
especially for the case when the device model runs in a
stub
Re: [RFC PATCH 01/12] drivers/char: Add support for Xue USB3 debugger
On Mon, Jun 06, 2022 at 12:57:26PM -0400, Tamas K Lengyel wrote: > On Mon, Jun 6, 2022 at 10:10 AM Tamas K Lengyel > wrote: > > > > On Mon, Jun 6, 2022 at 10:03 AM Marek Marczykowski-Górecki > > wrote: > > > > > > On Mon, Jun 06, 2022 at 09:32:52AM -0400, Tamas K Lengyel wrote: > > > > > +/* Supported xHC PCI configurations */ > > > > > +#define XUE_XHC_CLASSC 0xC0330ULL > > > > > +#define XUE_XHC_VEN_INTEL 0x8086ULL > > > > > +#define XUE_XHC_DEV_Z370 0xA2AFULL > > > > > +#define XUE_XHC_DEV_Z390 0xA36DULL > > > > > +#define XUE_XHC_DEV_WILDCAT_POINT 0x9CB1ULL > > > > > +#define XUE_XHC_DEV_SUNRISE_POINT 0x9D2FULL > > > > > +#define XUE_XHC_DEV_CANNON_POINT 0x9DEDULL > > > > > > > > I had to add an extra device ID here to get it working on my NUC, > > > > would be nice if we could add that to the list of supported configs so > > > > I don't need to custom patch: > > > > > > > > #define XUE_XHC_DEV_COMET_LAKE 0x02EDULL > > > > > > > > The patch is here: > > > > https://github.com/tklengyel/xen/commit/dd0423aba6caa4ef41dff65470598a1c0c1105ae > > > > > > Interesting, I think known_xhc() is used only in the EFI variant of Xue. > > > Xen one just looks for any XHC based on the device class. And indeed, I > > > works for me on Tiger Lake that is not included here. > > > > > > I did need to select specific controller, since I have 3 of them: > > > 00:0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB > > > Controller (rev 01) > > > 00:0d.2 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI > > > #0 (rev 01) > > > 00:14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 > > > xHCI Host Controller (rev 20) > > > > > > So, I need dbgp=xue2 or dbgp=xue@pci00:14.0. > > > > Interesting! OK, I'll give that a shot and see if it works that way > > for me too, it's certainly been a while since I last tested :) > > Yeap, with console=dbgp dbgp=xue@pci00:14.0 it works as expected. > Xen's boot does hang if you don't have a debug cable connected or if > the other end is not plugged into the right USB3 port. Not sure if > that behavior is documented anywhere. Once I found the right USB3 port > on the machine that receives the debug output it started booting and > everything works expected (ie. one-way communication only). Indeed, the indefinite wait for the connection is not the most convenient. For debugging, I added some timeout, but it was based on the loop iterations not an actual time (not sure if there is any time source available at this early stage...). I'll see if this can be improved. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab signature.asc Description: PGP signature
Re: [RFC PATCH 01/12] drivers/char: Add support for Xue USB3 debugger
On Mon, Jun 6, 2022 at 10:10 AM Tamas K Lengyel wrote: > > On Mon, Jun 6, 2022 at 10:03 AM Marek Marczykowski-Górecki > wrote: > > > > On Mon, Jun 06, 2022 at 09:32:52AM -0400, Tamas K Lengyel wrote: > > > > +/* Supported xHC PCI configurations */ > > > > +#define XUE_XHC_CLASSC 0xC0330ULL > > > > +#define XUE_XHC_VEN_INTEL 0x8086ULL > > > > +#define XUE_XHC_DEV_Z370 0xA2AFULL > > > > +#define XUE_XHC_DEV_Z390 0xA36DULL > > > > +#define XUE_XHC_DEV_WILDCAT_POINT 0x9CB1ULL > > > > +#define XUE_XHC_DEV_SUNRISE_POINT 0x9D2FULL > > > > +#define XUE_XHC_DEV_CANNON_POINT 0x9DEDULL > > > > > > I had to add an extra device ID here to get it working on my NUC, > > > would be nice if we could add that to the list of supported configs so > > > I don't need to custom patch: > > > > > > #define XUE_XHC_DEV_COMET_LAKE 0x02EDULL > > > > > > The patch is here: > > > https://github.com/tklengyel/xen/commit/dd0423aba6caa4ef41dff65470598a1c0c1105ae > > > > Interesting, I think known_xhc() is used only in the EFI variant of Xue. > > Xen one just looks for any XHC based on the device class. And indeed, I > > works for me on Tiger Lake that is not included here. > > > > I did need to select specific controller, since I have 3 of them: > > 00:0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB > > Controller (rev 01) > > 00:0d.2 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI > > #0 (rev 01) > > 00:14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 > > xHCI Host Controller (rev 20) > > > > So, I need dbgp=xue2 or dbgp=xue@pci00:14.0. > > Interesting! OK, I'll give that a shot and see if it works that way > for me too, it's certainly been a while since I last tested :) Yeap, with console=dbgp dbgp=xue@pci00:14.0 it works as expected. Xen's boot does hang if you don't have a debug cable connected or if the other end is not plugged into the right USB3 port. Not sure if that behavior is documented anywhere. Once I found the right USB3 port on the machine that receives the debug output it started booting and everything works expected (ie. one-way communication only). Tamas
Re: [PATCH] xen: unexport __init-annotated xen_xlate_map_ballooned_pages()
On 06.06.22 07:59, Masahiro Yamada wrote:
Hello
EXPORT_SYMBOL and __init is a bad combination because the .init.text
section is freed up after the initialization. Hence, modules cannot
use symbols annotated __init. The access to a freed symbol may end up
with kernel panic.
modpost used to detect it, but it has been broken for a decade.
Recently, I fixed modpost so it started to warn it again, then this
showed up in linux-next builds.
There are two ways to fix it:
- Remove __init
- Remove EXPORT_SYMBOL
I chose the latter for this case because none of the in-tree call-sites
(arch/arm/xen/enlighten.c, arch/x86/xen/grant-table.c) is compiled as
modular.
Good description.
Fixes: 243848fc018c ("xen/grant-table: Move xlated_setup_gnttab_pages to common
place")
Reported-by: Stephen Rothwell
Signed-off-by: Masahiro Yamada
I think the patch is correct.
Reviewed-by: Oleksandr Tyshchenko
---
drivers/xen/xlate_mmu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
index 34742c6e189e..f17c4c03db30 100644
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -261,7 +261,6 @@ int __init xen_xlate_map_ballooned_pages(xen_pfn_t **gfns,
void **virt,
return 0;
}
-EXPORT_SYMBOL_GPL(xen_xlate_map_ballooned_pages);
struct remap_pfn {
struct mm_struct *mm;
--
Regards,
Oleksandr Tyshchenko
[linux-5.4 test] 170843: regressions - FAIL
flight 170843 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/170843/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 170736 test-armhf-armhf-xl-credit2 14 guest-start fail REGR. vs. 170736 test-armhf-armhf-xl-credit1 14 guest-start fail REGR. vs. 170736 Tests which did not succeed, but are not blocking: test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-xl-pvshim 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-shadow 1 build-check(1) blocked n/a test-amd64-i386-xl-vhd1 build-check(1) blocked n/a test-amd64-i386-examine 1 build-check(1) blocked n/a test-amd64-coresched-i386-xl 1 build-check(1) blocked n/a test-amd64-coresched-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-shadow1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-ws16-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvshim1 build-check(1) blocked n/a test-amd64-amd64-dom0pvh-xl-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-intel 1 build-check(1) blocked n/a test-amd64-amd64-examine 1 build-check(1) blocked n/a test-amd64-amd64-examine-bios 1 build-check(1) blocked n/a test-amd64-amd64-examine-uefi 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvhv2-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit1 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd11-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-freebsd12-amd64 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-amd 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ws16-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-examine-bios 1 build-check(1) blocked n/a test-amd64-i386-examine-uefi 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a
Re: [RFC PATCH 01/12] drivers/char: Add support for Xue USB3 debugger
On Mon, Jun 6, 2022 at 10:03 AM Marek Marczykowski-Górecki wrote: > > On Mon, Jun 06, 2022 at 09:32:52AM -0400, Tamas K Lengyel wrote: > > > +/* Supported xHC PCI configurations */ > > > +#define XUE_XHC_CLASSC 0xC0330ULL > > > +#define XUE_XHC_VEN_INTEL 0x8086ULL > > > +#define XUE_XHC_DEV_Z370 0xA2AFULL > > > +#define XUE_XHC_DEV_Z390 0xA36DULL > > > +#define XUE_XHC_DEV_WILDCAT_POINT 0x9CB1ULL > > > +#define XUE_XHC_DEV_SUNRISE_POINT 0x9D2FULL > > > +#define XUE_XHC_DEV_CANNON_POINT 0x9DEDULL > > > > I had to add an extra device ID here to get it working on my NUC, > > would be nice if we could add that to the list of supported configs so > > I don't need to custom patch: > > > > #define XUE_XHC_DEV_COMET_LAKE 0x02EDULL > > > > The patch is here: > > https://github.com/tklengyel/xen/commit/dd0423aba6caa4ef41dff65470598a1c0c1105ae > > Interesting, I think known_xhc() is used only in the EFI variant of Xue. > Xen one just looks for any XHC based on the device class. And indeed, I > works for me on Tiger Lake that is not included here. > > I did need to select specific controller, since I have 3 of them: > 00:0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB > Controller (rev 01) > 00:0d.2 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0 > (rev 01) > 00:14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI > Host Controller (rev 20) > > So, I need dbgp=xue2 or dbgp=xue@pci00:14.0. Interesting! OK, I'll give that a shot and see if it works that way for me too, it's certainly been a while since I last tested :) Thanks, Tamas
Re: [RFC PATCH 01/12] drivers/char: Add support for Xue USB3 debugger
On Mon, Jun 06, 2022 at 09:32:52AM -0400, Tamas K Lengyel wrote: > > +/* Supported xHC PCI configurations */ > > +#define XUE_XHC_CLASSC 0xC0330ULL > > +#define XUE_XHC_VEN_INTEL 0x8086ULL > > +#define XUE_XHC_DEV_Z370 0xA2AFULL > > +#define XUE_XHC_DEV_Z390 0xA36DULL > > +#define XUE_XHC_DEV_WILDCAT_POINT 0x9CB1ULL > > +#define XUE_XHC_DEV_SUNRISE_POINT 0x9D2FULL > > +#define XUE_XHC_DEV_CANNON_POINT 0x9DEDULL > > I had to add an extra device ID here to get it working on my NUC, > would be nice if we could add that to the list of supported configs so > I don't need to custom patch: > > #define XUE_XHC_DEV_COMET_LAKE 0x02EDULL > > The patch is here: > https://github.com/tklengyel/xen/commit/dd0423aba6caa4ef41dff65470598a1c0c1105ae Interesting, I think known_xhc() is used only in the EFI variant of Xue. Xen one just looks for any XHC based on the device class. And indeed, I works for me on Tiger Lake that is not included here. I did need to select specific controller, since I have 3 of them: 00:0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller (rev 01) 00:0d.2 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0 (rev 01) 00:14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller (rev 20) So, I need dbgp=xue2 or dbgp=xue@pci00:14.0. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab signature.asc Description: PGP signature
[xen-tip:linux-next 6/10] drivers/xen/grant-dma-ops.c:278:6: warning: no previous prototype for 'xen_grant_setup_dma_ops'
Hi Juergen,
First bad commit (maybe != root cause):
tree: https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux-next
head: bb1b8419ea23d8d2de3c886a540f41e39dfe82a9
commit: 6b268a48884cf8ef00477a0e652864638391587c [6/10] xen/virtio: Enable
restricted memory access using Xen grant mappings
config: x86_64-allyesconfig
(https://download.01.org/0day-ci/archive/20220606/202206062149.cnjvofb7-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-1) 11.3.0
reproduce (this is a W=1 build):
#
https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git/commit/?id=6b268a48884cf8ef00477a0e652864638391587c
git remote add xen-tip
https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
git fetch --no-tags xen-tip linux-next
git checkout 6b268a48884cf8ef00477a0e652864638391587c
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/net/usb/
drivers/xen/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/xen/grant-dma-ops.c:278:6: warning: no previous prototype for
>> 'xen_grant_setup_dma_ops' [-Wmissing-prototypes]
278 | void xen_grant_setup_dma_ops(struct device *dev)
| ^~~
vim +/xen_grant_setup_dma_ops +278 drivers/xen/grant-dma-ops.c
2c73e39aceb90b Juergen Gross 2022-06-02 277
2c73e39aceb90b Juergen Gross 2022-06-02 @278 void
xen_grant_setup_dma_ops(struct device *dev)
2c73e39aceb90b Juergen Gross 2022-06-02 279 {
2c73e39aceb90b Juergen Gross 2022-06-02 280struct xen_grant_dma_data *data;
2c73e39aceb90b Juergen Gross 2022-06-02 281
2c73e39aceb90b Juergen Gross 2022-06-02 282data =
find_xen_grant_dma_data(dev);
2c73e39aceb90b Juergen Gross 2022-06-02 283if (data) {
2c73e39aceb90b Juergen Gross 2022-06-02 284dev_err(dev, "Xen grant
DMA data is already created\n");
2c73e39aceb90b Juergen Gross 2022-06-02 285return;
2c73e39aceb90b Juergen Gross 2022-06-02 286}
2c73e39aceb90b Juergen Gross 2022-06-02 287
2c73e39aceb90b Juergen Gross 2022-06-02 288data = devm_kzalloc(dev,
sizeof(*data), GFP_KERNEL);
2c73e39aceb90b Juergen Gross 2022-06-02 289if (!data)
2c73e39aceb90b Juergen Gross 2022-06-02 290goto err;
2c73e39aceb90b Juergen Gross 2022-06-02 291
2c73e39aceb90b Juergen Gross 2022-06-02 292/* XXX The dom0 is hardcoded as
the backend domain for now */
2c73e39aceb90b Juergen Gross 2022-06-02 293data->backend_domid = 0;
2c73e39aceb90b Juergen Gross 2022-06-02 294
2c73e39aceb90b Juergen Gross 2022-06-02 295if
(xa_err(xa_store(_grant_dma_devices, (unsigned long)dev, data,
2c73e39aceb90b Juergen Gross 2022-06-02 296GFP_KERNEL))) {
2c73e39aceb90b Juergen Gross 2022-06-02 297dev_err(dev, "Cannot
store Xen grant DMA data\n");
2c73e39aceb90b Juergen Gross 2022-06-02 298goto err;
2c73e39aceb90b Juergen Gross 2022-06-02 299}
2c73e39aceb90b Juergen Gross 2022-06-02 300
2c73e39aceb90b Juergen Gross 2022-06-02 301dev->dma_ops =
_grant_dma_ops;
2c73e39aceb90b Juergen Gross 2022-06-02 302
2c73e39aceb90b Juergen Gross 2022-06-02 303return;
2c73e39aceb90b Juergen Gross 2022-06-02 304
2c73e39aceb90b Juergen Gross 2022-06-02 305 err:
2c73e39aceb90b Juergen Gross 2022-06-02 306dev_err(dev, "Cannot set up Xen
grant DMA ops, retain platform DMA ops\n");
2c73e39aceb90b Juergen Gross 2022-06-02 307 }
2c73e39aceb90b Juergen Gross 2022-06-02 308
:: The code at line 278 was first introduced by commit
:: 2c73e39aceb90b59058cdbc497916049e798963c xen/grant-dma-ops: Add option
to restrict memory access under Xen
:: TO: Juergen Gross
:: CC: Juergen Gross
--
0-DAY CI Kernel Test Service
https://01.org/lkp
Re: [RFC PATCH 00/12] Add Xue - console over USB 3 Debug Capability
On Mon, Jun 06, 2022 at 01:18:45PM +, Andrew Cooper wrote: > On 06/06/2022 04:40, Marek Marczykowski-Górecki wrote: > > This is integration of https://github.com/connojd/xue into mainline Xen. > > This patch series includes several patches that I made in the process, some > > are > > very loosely related. > > Thanks for looking into this. CC'ing Connor just so he's aware. > > > > > The RFC status is to collect feedback on the shape of this series, > > specifically: > > > > 1. The actual Xue driver is a header-only library. Most of the code is in a > > series of inline functions in xue.h. I kept it this way, to ease integrating > > Xue updates. That's also why I preserved its original code style. Is it > > okay, > > or should I move the code to a .c file? > > It doesn't matter much if it's a .h or .c file. It could perfectly > easily live as xen/drivers/char/xue.h and included only by xue.c. (More > specifically, it doesn't want to live as xen/include/xue.h) > > That said, as soon as you get to patch 2, it's no longer unmodified from > upstream, and with patch 3, we're gaining concrete functionality that > upstream doesn't have. > > > > > 2. The xue.h file includes bindings for several other environments too (EFI, > > Linux, ...). This is unused code, behind #ifdef. Again, I kept it to ease > > updating. Should I remove it? > > Drop please. Xen is an embedded environment, and support other > environments is a waste of space and time. > > I'm slowly ripping out other examples. With both the above answers, I'll see how much work will be refactoring it into Xen-only driver. Dropping other environments should make xue_ops abstraction unnecessary, which should simplify the code quite a bit. > > 3. The adding of IOMMU reserverd memory is necessary even if "hiding" device > > from dom0. Otherwise, VT-d will deny DMA. That's probably not the most > > elegant > > solution, but Xen doesn't have seem to have provisions for devices doing DMA > > into Xen's memory. > > I think that's to be expected, as the device should end up in quarantine. > > That said, the model is broken for devices that Xen exclusively uses, > which includes IOMMU devices. IOMMUs don't have any kind of applicable > IOMMU context, and things used exclusively by Xen don't want to be in > the general quarantine pool, because then all malicious devices can > interfere with the ringbuffer. That's yet another reason for assigning it to dom0... this way, only dom0(-assigned devices) can interfere with the ringbuffer. That's still sub-optimal, but the current granularity of IOMMU configuration in Xen doesn't allow to do any better. I'll drop patch 11. > > 4. To preserve authorship, I included unmodified "drivers/char: Add support > > for > > Xue USB3 debugger" commit from Connor, and only added my changes on top. > > This > > means, with that this commit, the driver doesn't work yet (but it does > > compile). Is it okay, or should I combine fixes into that commit and somehow > > mark authorship in the commit message? > > That depends on how much changes. Other options are a dual SoB with > Connor still as the author (I typically do this for substantial code > movement, programmatic changes, etc), or for a major rewrite, changing > authorship and being very clear in the commit message where the code > originated. If I'll go with the refactor to get rid of xue_ops, then indeed it makes more sense to create new commit and reference code origin in the commit message. > > 5. The last patch(es) enable using the controller by dom0, even when Xen > > uses DbC part. That's possible, because the capability was designed > > specifically to allow separate driver handle it, in parallel to unmodified > > xhci > > driver (separate set of registers, pretending the port is "disconnected" for > > the main xhci driver etc). It works with Linux dom0, although requires an > > awful > > hack - re-enabling bus mastering behind dom0's backs. Is it okay to leave > > this > > functionality as is, or guard it behind some cmdline option, or maybe remove > > completely? > > "Xen is configured to use USB3 debugging" is the only relevant signal. > We do not want anything else. If this triggers hacks for dom0, then fine. I'm worried here about depending on specific dom0 behavior. With the current Linux driver, I needed just the bus mastering hack, but since in this case dom0 has more or less full control over the controller, there could be other ways it could disrupt DbC in the future. > OOI, how does the dual driver stack work in Linux? At a minimum they've > surely got to coordinate device resets. Kind of. The DbC driver (both Linux and Xue) checks if nothing hasn't disabled DbC in the meantime (for example via device reset). When it happens, it re-enables it back. I haven't tried what happens if I try to enable DbC both in Xen and Linux at the same time, but one of the possibilities is spectacular explosion. (In theory Xen should win, since
Re: [XEN PATCH 3/4] build: replace get-fields.sh by a perl script
On Wed, Jun 01, 2022 at 10:32:10AM -0700, Elliott Mitchell wrote: > On Wed, Jun 01, 2022 at 05:59:08PM +0100, Anthony PERARD wrote: > > diff --git a/xen/tools/compat-xlat-header b/xen/tools/compat-xlat-header > > new file mode 100755 > > index 00..f1f42a9dde > > --- /dev/null > > +++ b/xen/tools/compat-xlat-header > > @@ -0,0 +1,539 @@ > > +#!/usr/bin/perl -w > > + > > +use strict; > > +use warnings; > > I hope to take more of a look at this, but one thing I immediately > notice: -w is redundant with "use warnings;". I strongly prefer > "use warnings;", but others may have different preferences. Sounds good, I might have copy the shebang and the "use*" from an other script in our repo, without checking what the -w stand for. Thanks, -- Anthony PERARD
Re: [XEN PATCH 2/4] build: set PERL
On Thu, Jun 02, 2022 at 11:01:30AM +0200, Jan Beulich wrote: > On 01.06.2022 18:59, Anthony PERARD wrote: > > --- a/xen/Makefile > > +++ b/xen/Makefile > > @@ -22,6 +22,7 @@ PYTHON_INTERPRETER:= $(word 1,$(shell which > > python3 python python2 2>/dev/null) > > export PYTHON ?= $(PYTHON_INTERPRETER) > > > > export CHECKPOLICY ?= checkpolicy > > +export PERL?= perl > > For the intended use, is there a minimum version requirement? If so, > it needs documenting in ./README (and it preferably wouldn't be any > newer than from around the times our other dependencies are). And > even when the uses are fully backwards compatible, I think the need > for the tool wants mentioning there. I don't think there's a minimum version. The script works in our Gitlab CI, or at least the builds don't break. Yes, it would be better to document the tool, I'll add it to the README. (We already use it in the toolstack, at least for libxl, so it was at least partially needed before.) Thanks, -- Anthony PERARD
Re: [XEN PATCH 1/4] build: xen/include: use if_changed
On Thu, Jun 02, 2022 at 11:11:15AM +0200, Jan Beulich wrote: > On 01.06.2022 18:59, Anthony PERARD wrote: > > Use "define" for the headers*_chk commands as otherwise the "#" > > is interpreted as a comment and make can't find the end of > > $(foreach,). > > In cmd_xlat_lst you use $(pound) - any reason this doesn't work in > these rules? Note that I don't mind the use of "define", just that I'm > puzzled by the justification. I think I just forgot about $(pound) when I tried to debug why the command didn't work in some environment (that is when not using define). I think the second thing that make me not replacing '#' by "$(pound)" is that reading "#include" in the Makefile is probably better that reading "$(pound)include". I guess we should add something to the justification like: That allow us to keep writing "#include" in the Makefile without having to replace that by "$(pound)include" which would be a bit less obvious about the command line purpose. Thanks, -- Anthony PERARD
Re: [RFC PATCH 00/12] Add Xue - console over USB 3 Debug Capability
On Mon, Jun 06, 2022 at 01:18:42PM +, Lengyel, Tamas wrote: > Happy to see this effort, it's been long overdue to get this feature > upstream! If you have a git branch somewhere I'm happy to test it out. I > already have tested Xue before on my NUC and it was working well. It's here: https://github.com/marmarek/xen/tree/master-xue warning: I do force-push to this branch from time to time -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab signature.asc Description: PGP signature
Re: [RFC PATCH 01/12] drivers/char: Add support for Xue USB3 debugger
> +/* Supported xHC PCI configurations */ > +#define XUE_XHC_CLASSC 0xC0330ULL > +#define XUE_XHC_VEN_INTEL 0x8086ULL > +#define XUE_XHC_DEV_Z370 0xA2AFULL > +#define XUE_XHC_DEV_Z390 0xA36DULL > +#define XUE_XHC_DEV_WILDCAT_POINT 0x9CB1ULL > +#define XUE_XHC_DEV_SUNRISE_POINT 0x9D2FULL > +#define XUE_XHC_DEV_CANNON_POINT 0x9DEDULL I had to add an extra device ID here to get it working on my NUC, would be nice if we could add that to the list of supported configs so I don't need to custom patch: #define XUE_XHC_DEV_COMET_LAKE 0x02EDULL The patch is here: https://github.com/tklengyel/xen/commit/dd0423aba6caa4ef41dff65470598a1c0c1105ae Thanks, Tamas
Re: [PATCH v2 1/3] x86/vmx: implement Bus Lock detection
On 26/05/2022 12:11, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index f08a00dcbb..476ab72463 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -4065,6 +4065,16 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>
> if ( unlikely(exit_reason & VMX_EXIT_REASONS_FAILED_VMENTRY) )
> return vmx_failed_vmentry(exit_reason, regs);
> +if ( unlikely(exit_reason & VMX_EXIT_REASONS_BUS_LOCK) )
> +{
> +/*
> + * Delivery of Bus Lock VM exit was pre-empted by a higher priority
> VM
> + * exit.
> + */
> +exit_reason &= ~VMX_EXIT_REASONS_BUS_LOCK;
> +if ( exit_reason != EXIT_REASON_BUS_LOCK )
> +perfc_incr(buslock);
> +}
I know this post-dates you posting v2, but given the latest update from
Intel, VMX_EXIT_REASONS_BUS_LOCK will be set on all exits.
So the code logic would be simpler as:
if ( exit_reason & VMX_EXIT_REASONS_BUS_LOCK )
{
perfc_incr(buslock);
exit_reason &= ~VMX_EXIT_REASONS_BUS_LOCK;
}
and ...
>
> if ( v->arch.hvm.vmx.vmx_realmode )
> {
> @@ -4561,6 +4571,14 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
> vmx_handle_descriptor_access(exit_reason);
> break;
>
> +case EXIT_REASON_BUS_LOCK:
> +perfc_incr(buslock);
... dropping this perf counter.
With something along these lines, Reviewed-by: Andrew Cooper
Re: [XEN PATCH 0/4] xen: rework compat headers generation
On Wed, Jun 01, 2022 at 05:17:36PM +, Andrew Cooper wrote: > On 01/06/2022 17:59, Anthony PERARD wrote: > > Patch series available in this git branch: > > https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git > > br.build-system-xen-include-rework-v1 > > > > Hi, > > > > This patch series is about 2 improvement. First one is to use $(if_changed, > > ) > > in "include/Makefile" to make the generation of the compat headers less > > verbose > > and to have the command line part of the decision to rebuild the headers. > > Second one is to replace one slow script by a much faster one, and save time > > when generating the headers. > > > > Thanks. > > > > Anthony PERARD (4): > > build: xen/include: use if_changed > > build: set PERL > > build: replace get-fields.sh by a perl script > > build: remove auto.conf prerequisite from compat/xlat.h target > > > > xen/Makefile | 1 + > > xen/include/Makefile | 106 --- > > xen/tools/compat-xlat-header | 539 +++ > > xen/tools/get-fields.sh | 528 -- > > Excellent. I was planning to ask you about this. (I also need to > refreshing my half series cleaning up other bits of the build.) > > One trivial observation is that it would probably be nicer to name the > script with a .pl extension. Sound fine, I don't think it matter much here. > Any numbers on what the speedup in patch 3 is? Yes, on my machine when doing a full build, with `ccache` enabled, it saves about 1.17 seconds (out of ~17s), and without ccache, it saves about 2.0 seconds (out of ~37s). Without ccache: before: $ for i in `seq 4`; do time make -j$(nproc) -s O=build 2>/dev/null >/dev/null; rm -r build; done make --no-print-directory -j$(nproc) -s O=build > /dev/null 244.98s user 29.24s system 683% cpu 40.146 total make --no-print-directory -j$(nproc) -s O=build > /dev/null 47.05s user 11.50s system 332% cpu 17.610 total make --no-print-directory -j$(nproc) -s O=build > /dev/null 47.35s user 11.22s system 330% cpu 17.733 total make --no-print-directory -j$(nproc) -s O=build > /dev/null 47.31s user 11.23s system 333% cpu 17.577 total after: $ for i in `seq 4`; do time make -j$(nproc) -s O=build 2>/dev/null>/dev/null; rm -r build; done make --no-print-directory -j$(nproc) -s O=build 2> /dev/null > /dev/null 237.28s user 25.97s system 667% cpu 39.456 total make --no-print-directory -j$(nproc) -s O=build 2> /dev/null > /dev/null 37.60s user 8.20s system 282% cpu 16.214 total make --no-print-directory -j$(nproc) -s O=build 2> /dev/null > /dev/null 37.95s user 8.67s system 279% cpu 16.651 total make --no-print-directory -j$(nproc) -s O=build 2> /dev/null > /dev/null 38.02s user 8.40s system 280% cpu 16.545 total And without ccache: before: $ for i in `seq 4`; do time make -j$(nproc) -s O=build 2>/dev/null>/dev/null; rm -r build; done make --no-print-directory -j$(nproc) -s O=build 2> /dev/null > /dev/null 206.37s user 22.19s system 640% cpu 35.695 total make --no-print-directory -j$(nproc) -s O=build 2> /dev/null > /dev/null 221.45s user 22.26s system 667% cpu 36.537 total make --no-print-directory -j$(nproc) -s O=build 2> /dev/null > /dev/null 233.95s user 23.80s system 686% cpu 37.518 total make --no-print-directory -j$(nproc) -s O=build 2> /dev/null > /dev/null 234.27s user 23.83s system 680% cpu 37.923 total after: $ for i in `seq 4`; do time make -j$(nproc) -s O=build 2>/dev/null>/dev/null; rm -r build; done make --no-print-directory -j$(nproc) -s O=build 2> /dev/null > /dev/null 198.62s user 18.64s system 642% cpu 33.841 total make --no-print-directory -j$(nproc) -s O=build 2> /dev/null > /dev/null 202.91s user 19.46s system 655% cpu 33.912 total make --no-print-directory -j$(nproc) -s O=build 2> /dev/null > /dev/null 224.42s user 20.89s system 680% cpu 36.025 total make --no-print-directory -j$(nproc) -s O=build 2> /dev/null > /dev/null 222.93s user 21.29s system 683% cpu 35.708 total > Are the generated compat headers identical before and after this > series? If yes, I'm very tempted to ack and commit it straight away. Yes, the headers are identical. Hopefully, I've managed to check with all compat headers enabled, since that depends on .config. Cheers, -- Anthony PERARD
[linux-linus test] 170841: regressions - FAIL
flight 170841 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/170841/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-xl-pvhv2-intel 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-qemuu-nested-intel 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-raw 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-pair 12 xen-boot/src_host fail REGR. vs. 170714 test-amd64-amd64-libvirt-pair 13 xen-boot/dst_host fail REGR. vs. 170714 test-amd64-amd64-freebsd12-amd64 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-seattle 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-libvirt-qcow2 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-examine 8 reboot fail REGR. vs. 170714 test-arm64-arm64-xl-credit2 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-credit1 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-libvirt-raw 8 xen-boot fail REGR. vs. 170714 test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 170714 test-amd64-amd64-examine-bios 8 reboot fail REGR. vs. 170714 test-amd64-amd64-examine-uefi 8 reboot fail REGR. vs. 170714 test-amd64-amd64-examine 8 reboot fail REGR. vs. 170714 test-arm64-arm64-libvirt-xsm 8 xen-boot fail REGR. vs. 170714 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170714 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170714 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170714 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 170714 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170714 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170714 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170714 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170714 test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-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-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 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-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 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-raw 14 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-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-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 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: linuxf2906aa863381afb0015a9eb7fefad885d4e5a56 baseline version: linuxd6ecaa0024485effd065124fe774de2e22095f2d Last test of basis 170714 2022-05-24 03:27:44 Z 13 days Failing since170716 2022-05-24 11:12:06 Z 13 days 37 attempts Testing same since 170841 2022-06-06 03:15:23 Z0 days1 attempts 2274 people touched revisions under test, not listing them all jobs: build-amd64-xsm
RE: [RFC PATCH 00/12] Add Xue - console over USB 3 Debug Capability
> -Original Message- > From: Xen-devel On Behalf Of Marek > Marczykowski-Górecki > Sent: Sunday, June 5, 2022 11:40 PM > To: xen-devel@lists.xenproject.org > Cc: Marczykowski, Marek ; Cooper, Andrew > ; George Dunlap ; > Beulich, Jan ; Julien Grall ; Stefano > Stabellini ; Wei Liu ; Pau Monné, Roger > ; Paul Durrant ; Tian, Kevin > > Subject: [RFC PATCH 00/12] Add Xue - console over USB 3 Debug Capability > > This is integration of https://github.com/connojd/xue into mainline Xen. > This patch series includes several patches that I made in the process, some > are > very loosely related. > > The RFC status is to collect feedback on the shape of this series, > specifically: > > 1. The actual Xue driver is a header-only library. Most of the code is in a > series of > inline functions in xue.h. I kept it this way, to ease integrating Xue > updates. > That's also why I preserved its original code style. Is it okay, or should I > move the > code to a .c file? > > 2. The xue.h file includes bindings for several other environments too (EFI, > Linux, > ...). This is unused code, behind #ifdef. Again, I kept it to ease updating. > Should I > remove it? > > 3. The adding of IOMMU reserverd memory is necessary even if "hiding" device > from dom0. Otherwise, VT-d will deny DMA. That's probably not the most > elegant solution, but Xen doesn't have seem to have provisions for devices > doing > DMA into Xen's memory. > > 4. To preserve authorship, I included unmodified "drivers/char: Add support > for > Xue USB3 debugger" commit from Connor, and only added my changes on top. > This means, with that this commit, the driver doesn't work yet (but it does > compile). Is it okay, or should I combine fixes into that commit and somehow > mark authorship in the commit message? > > 5. The last patch(es) enable using the controller by dom0, even when Xen uses > DbC part. That's possible, because the capability was designed specifically to > allow separate driver handle it, in parallel to unmodified xhci driver > (separate set > of registers, pretending the port is "disconnected" for the main xhci driver > etc). > It works with Linux dom0, although requires an awful hack - re-enabling bus > mastering behind dom0's backs. Is it okay to leave this functionality as is, > or > guard it behind some cmdline option, or maybe remove completely? Happy to see this effort, it's been long overdue to get this feature upstream! If you have a git branch somewhere I'm happy to test it out. I already have tested Xue before on my NUC and it was working well. Thanks, Tamas
[libvirt test] 170842: regressions - FAIL
flight 170842 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/170842/ 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 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a version targeted for testing: libvirt a939d4d86919a1f9ffcdc053a852422f9184a00d baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 696 days Failing since151818 2020-07-11 04:18:52 Z 695 days 677 attempts Testing same since 170825 2022-06-04 04:20:31 Z2 days3 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Amneesh Singh Andika Triwidada Andrea Bolognani Andrew Melnychenko Ani Sinha Balázs Meskó Barrett Schonefeld Bastian Germann Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Bjoern Walk Boris Fiuczynski Brad Laue Brian Turek Bruno Haible Chris Mayo Christian Borntraeger Christian Ehrhardt Christian Kirbach Christian Schoenebeck Christophe Fergeau Claudio Fontana Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Didik Supriadi dinglimin Divya Garg Dmitrii Shcherbakov Dmytro Linkin Eiichi Tsukata Emilio Herrera Eric Farman Erik Skultety Fabian Affolter Fabian Freyer Fabiano Fidêncio Fangge Jin Farhan Ali Fedora Weblate Translation Franck Ridel Gavi Teitz gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Haonan Wang Hela Basa Helmut Grohne Hiroki Narukawa Hyman Huang(黄勇) Ian Wienand Ioanna Alifieraki Ivan Teterevkov Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen jason lee Jean-Baptiste Holcroft Jia Zhou Jianan Gao Jim Fehlig Jin Yan Jing Qi Jinsheng Zhang Jiri Denemark Joachim Falk John Ferlan John Levon John Levon Jonathan Watt Jonathon Jongsma Julio Faracco Justin Gatzen Ján Tomko Kashyap Chamarthy Kevin Locke Kim InSoo Koichi Murase Kristina Hanicova Laine Stump Laszlo Ersek Lee Yarwood Lei Yang Lena Voytek Liang Yan Liang Yan Liao Pingfang Lin Ma Lin Ma Lin Ma Liu Yiding Lubomir Rintel Luke Yue Luyao Zhong luzhipeng Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Martin Pitt Masayoshi Mizuma Matej Cepl Matt Coleman Matt Coleman Mauro Matteo Cascella Max Goodhart Maxim Nestratov Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Moteen Shah Moteen Shah Muha Aliss Nathan Neal Gompa Nick Chevsky Nick Shyrokovskiy Nickys Music Group Nico Pache Nicolas Lécureuil Nicolas Lécureuil Nikolay Shirokovskiy Nikolay Shirokovskiy Nikolay Shirokovskiy Niteesh Dubey Olaf Hering Olesya Gerasimenko Or Ozeri Orion Poplawski Pany Paolo Bonzini Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peng Liang Peter Krempa Pino
Re: [PATCH v2 3/4] arm: add ISAR2, MMFR0 and MMFR1 fields in cpufeature
Hi Stefano,
> On 3 Jun 2022, at 02:45, Stefano Stabellini wrote:
>
> On Tue, 31 May 2022, Bertrand Marquis wrote:
>> Complete AA64ISAR2 and AA64MMFR[0-1] with more fields.
>> While there add a comment for MMFR bitfields as for other registers in
>> the cpuinfo structure definition.
>>
>> Signed-off-by: Bertrand Marquis
>> ---
>> Changes in v2:
>> - patch introduced to isolate changes in cpufeature.h
>> - complete MMFR0 and ISAR2 to sync with sysregs.h status
>> ---
>> xen/arch/arm/include/asm/cpufeature.h | 28 ++-
>> 1 file changed, 23 insertions(+), 5 deletions(-)
>>
>> diff --git a/xen/arch/arm/include/asm/cpufeature.h
>> b/xen/arch/arm/include/asm/cpufeature.h
>> index 9649a7afee..57eb6773d3 100644
>> --- a/xen/arch/arm/include/asm/cpufeature.h
>> +++ b/xen/arch/arm/include/asm/cpufeature.h
>> @@ -234,6 +234,7 @@ struct cpuinfo_arm {
>> union {
>> register_t bits[3];
>> struct {
>> + /* MMFR0 */
>> unsigned long pa_range:4;
>> unsigned long asid_bits:4;
>> unsigned long bigend:4;
>> @@ -242,18 +243,31 @@ struct cpuinfo_arm {
>> unsigned long tgranule_16K:4;
>> unsigned long tgranule_64K:4;
>> unsigned long tgranule_4K:4;
>> - unsigned long __res0:32;
>> -
>> + unsigned long tgranule_16k_2:4;
>> + unsigned long tgranule_64k_2:4;
>> + unsigned long tgranule_4k:4;
>
> Should be tgranule_4k_2:4
Right I will fix that.
>
>
>> + unsigned long exs:4;
>> + unsigned long __res0:8;
>> + unsigned long fgt:4;
>> + unsigned long ecv:4;
>> +
>> + /* MMFR1 */
>> unsigned long hafdbs:4;
>> unsigned long vmid_bits:4;
>> unsigned long vh:4;
>> unsigned long hpds:4;
>> unsigned long lo:4;
>> unsigned long pan:4;
>> - unsigned long __res1:8;
>> - unsigned long __res2:28;
>> + unsigned long specsei:4;
>> + unsigned long xnx:4;
>> + unsigned long twed:4;
>> + unsigned long ets:4;
>> + unsigned long __res1:4;
>
> hcx?
>
>
>> + unsigned long afp:4;
>> + unsigned long __res2:12;
>
> ntlbpa
> tidcp1
> cmow
>
>> unsigned long ecbhb:4;
>
> Strangely enough I am looking at DDI0487H and ecbhb is not there
> (D13.2.65). Am I looking at the wrong location?
Right now I declared here only the values which have a corresponding
declaration in sysregs.h
If I add more fields here we will not be in sync with it anymore.
And on ecbhb it will be in the next revision of the manual yes.
>
>
>> + /* MMFR2 */
>> unsigned long __res3:64;
>> };
>> } mm64;
>> @@ -297,7 +311,11 @@ struct cpuinfo_arm {
>> unsigned long __res2:8;
>>
>> /* ISAR2 */
>> - unsigned long __res3:28;
>> + unsigned long wfxt:4;
>> + unsigned long rpres:4;
>> + unsigned long gpa3:4;
>> + unsigned long apa3:4;
>> + unsigned long __res3:12;
>
> mops
> bc
> pac_frac
>
>
>> unsigned long clearbhb:4;
>
> And again this is not described at D13.2.63. Probably the bhb stuff
> didn't make it into the ARM ARM yet.
As said before, are you ok with only adding stuff declared in sysregs
to make it simpler to sync with Linux ?
Cheers
Bertrand
>
>
>>
>> unsigned long __res4:32;
>> --
>> 2.25.1
[xen-unstable test] 170840: FAIL
flight 170840 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/170840/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-xtf-amd64-amd64-3 broken in 170833 Tests which are failing intermittently (not blocking): test-xtf-amd64-amd64-3 5 host-install(5) broken in 170833 pass in 170840 test-amd64-i386-freebsd10-i386 7 xen-install fail pass in 170833 test-amd64-i386-pair 11 xen-install/dst_host fail pass in 170833 test-amd64-i386-livepatch 7 xen-installfail pass in 170833 test-armhf-armhf-xl-rtds 10 host-ping-check-xenfail pass in 170833 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-rtds15 migrate-support-check fail in 170833 never pass test-armhf-armhf-xl-rtds 16 saverestore-support-check fail in 170833 never pass test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170833 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170833 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170833 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170833 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 170833 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 170833 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170833 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170833 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 170833 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 170833 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 170833 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170833 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 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-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 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-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail 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-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-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 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-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 test-armhf-armhf-libvirt-raw 14 migrate-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-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass
