[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH v3 09/28] xen/vm_event: consolidate CONFIG_VM_EVENT


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Penny, Zheng" <penny.zheng@xxxxxxx>
  • Date: Tue, 11 Nov 2025 09:46:41 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=SRmkybsfnEO975H3bsyuVrhD4+SDTVTgo5Iq+4pho+I=; b=p7Rd++8kMEcNL8zZHRz+Wu8W0s/QBeKEgddn28L5f5i71VVuoU6YwrkTknvmTIM1SbOBmJpawGtnKUVb5YA8j08UnVOVhU+TbEEi8E/YCu/9TpUHZ+JBMfASK/zUJxBkDSLw4MmKjAH3x3byMIGIuzQEixtWiv7AlGiUqKfT+l5/ZEDvyxQvuQxk/QT3TKBSqFR9PJSoo/+nTFVRARHVhlI7QGduBVyd+PQOGTdLEX148v+o8Q3ftfv7TiT0pC9wNFUJn9E5Ae9mhD0gBwOwKJ3cC9VoIzC0fgdfglSIy0YtCRr0q+tpPi14L3/liY82wUGA7sHt0Mfuq1ILUlMj6g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=e3EpDjn8pcqBXWk//0YKLeXllXih948U4MJNTlVUO2LyeKP3K8iNbM1CCzLAkrt2lU6lMnNV4SIEuZIqSWKips3oD86kVL1fsgpSyxZn87MspwthyVZ4NcIHd803KdOz5elz1D1AdVJjh0BMK4TPXwwEyLrohj78Ru1fOYFXdtRmFj5H34+pbVLBBKWDLtqpGWtA84PSdP7lethKKYj4kkG5kW6SqdGAcNk22lfvAh4CAbR9M07C+s9Z320Mp8U1NZ/zdosKXO4ykgWTjPokvfn1tq3HxrFFTdZjgyej4+rJpiua7r1ja1SzRqDyzqJ7WjRE0zas74htOF299Jqh3g==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: "Huang, Ray" <Ray.Huang@xxxxxxx>, "oleksii.kurochko@xxxxxxxxx" <oleksii.kurochko@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, "Orzel, Michal" <Michal.Orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx>, Petre Pircalabu <ppircalabu@xxxxxxxxxxxxxxx>, "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
  • Delivery-date: Tue, 11 Nov 2025 09:47:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Msip_labels: MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Enabled=True;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SiteId=3dd8961f-e488-4e60-8e11-a82d994e183d;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_SetDate=2025-11-11T09:46:02.0000000Z;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Name=Open Source;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_ContentBits=3;MSIP_Label_f265efc6-e181-49d6-80f4-fae95cf838a0_Method=Privileged
  • Thread-index: AQHcPCqA+mY6s9fCEkmLa9SlVlA0PrTZYSAAgBPVwiCAABbwAIAAFwrQ
  • Thread-topic: [PATCH v3 09/28] xen/vm_event: consolidate CONFIG_VM_EVENT

[Public]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: Tuesday, November 11, 2025 4:14 PM
> To: Penny, Zheng <penny.zheng@xxxxxxx>
> Cc: Huang, Ray <Ray.Huang@xxxxxxx>; oleksii.kurochko@xxxxxxxxx; Andrew
> Cooper <andrew.cooper3@xxxxxxxxxx>; Roger Pau Monné <roger.pau@xxxxxxxxxx>;
> Anthony PERARD <anthony.perard@xxxxxxxxxx>; Orzel, Michal
> <Michal.Orzel@xxxxxxx>; Julien Grall <julien@xxxxxxx>; Stefano Stabellini
> <sstabellini@xxxxxxxxxx>; Alexandru Isaila <aisaila@xxxxxxxxxxxxxxx>; Petre
> Pircalabu <ppircalabu@xxxxxxxxxxxxxxx>; Daniel P. Smith
> <dpsmith@xxxxxxxxxxxxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; Tamas K
> Lengyel <tamas@xxxxxxxxxxxxx>
> Subject: Re: [PATCH v3 09/28] xen/vm_event: consolidate CONFIG_VM_EVENT
>
> On 11.11.2025 08:08, Penny, Zheng wrote:
> > [Public]
> >
> > Hi,
> >
> > Sorry for the late response. Just got back from long annual leaves
> >
> >> -----Original Message-----
> >>> --- a/xen/arch/x86/include/asm/mem_access.h
> >>> +++ b/xen/arch/x86/include/asm/mem_access.h
> >>> @@ -14,6 +14,7 @@
> >>>  #ifndef __ASM_X86_MEM_ACCESS_H__
> >>>  #define __ASM_X86_MEM_ACCESS_H__
> >>>
> >>> +#ifdef CONFIG_VM_EVENT
> >>>  /*
> >>>   * Setup vm_event request based on the access (gla is -1ull if not 
> >>> available).
> >>>   * Handles the rw2rx conversion. Boolean return value indicates if
> >>> event type @@ -25,6 +26,14 @@  bool p2m_mem_access_check(paddr_t
> >>> gpa, unsigned long gla,
> >>>                            struct npfec npfec,
> >>>                            struct vm_event_st **req_ptr);
> >>> +#else
> >>> +static inline bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
> >>> +                                        struct npfec npfec,
> >>> +                                        struct vm_event_st
> >>> +**req_ptr) {
> >>> +    return false;
> >>
> >> Leaving *req_ptr untouched feels dangerous; the fact that the sole
> >> caller has what it uses set to NULL up front is secondary.
> >>
> >
> > If we *req_ptr = NULL; compiler will not DCE the following code block when
> VM_EVENT=n:
> > ```
> >         if ( req_ptr )
> >         {
> >                 if ( monitor_traps(curr, sync, req_ptr) < 0 )
> >                         rc = 0;
> >
> >                 xfree(req_ptr);
> >         }
> >         return rc;
> > ```
> > Or am I misunderstanding what you suggest?
>
> First: It would have helped if you had also said where that code fragment 
> actually
> was taken from.
>
> Seeing it's in hvm_hap_nested_page_fault(), I'm having trouble following why 
> the
> compiler wouldn't be able to see that the local variable "req_ptr" there 
> would never
> change value, i.e. remain NULL throughout its lifetime. If indeed there's a 
> compiler
> shortcoming, that either wants working around or properly writing down.
>

This runtime undefined error will only occur when we turn on CONFIG_UBSAN(, 
then -fsanitize=undefined in CFLAG). Idk why....
But if we strengthen the condition check with vm_event_is_enabled(), we will 
pass even when UBSAN=y.
```
if ( req_ptr && vm_event_is_enabled(curr) )
```

> Jan

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.