[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH V2 07/23] xen/ioreq: Move x86's ioreq_gfn(server) to struct domain
 
- To: Jan Beulich <jbeulich@xxxxxxxx>
 
- From: Oleksandr <olekstysh@xxxxxxxxx>
 
- Date: Fri, 13 Nov 2020 16:05:01 +0200
 
- Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
 
- Delivery-date: Fri, 13 Nov 2020 14:05:24 +0000
 
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
 
 
 
On 12.11.20 13:21, Jan Beulich wrote:
Hi Jan
 
On 15.10.2020 18:44, Oleksandr Tyshchenko wrote:
 
--- a/xen/include/asm-x86/hvm/ioreq.h
+++ b/xen/include/asm-x86/hvm/ioreq.h
@@ -77,7 +77,7 @@ static inline int hvm_map_mem_type_to_ioreq_server(struct 
domain *d,
      if ( flags & ~XEN_DMOP_IOREQ_MEM_ACCESS_WRITE )
          return -EINVAL;
  
-    spin_lock_recursive(&d->arch.hvm.ioreq_server.lock);
+    spin_lock_recursive(&d->ioreq_server.lock);
   
      s = get_ioreq_server(d, id);
  
@@ -92,7 +92,7 @@ static inline int hvm_map_mem_type_to_ioreq_server(struct domain *d,
      rc = p2m_set_ioreq_server(d, flags, s);
  
   out:
-    spin_unlock_recursive(&d->arch.hvm.ioreq_server.lock);
+    spin_unlock_recursive(&d->ioreq_server.lock);
   
      if ( rc == 0 && flags == 0 )
      {
 
Does this build at this point, when !CONFIG_IOREQ_SERVER? Patch 1
moves the code here without guards, and patch 2, when introducing
the Kconfig symbol, doesn't add guards here. I admit I didn't
check further intermediate patches.
 
 
Yes.
 I can confirm I checked x86 patch by patch with CONFIG_IOREQ_SERVER, as 
for !CONFIG_IOREQ_SERVER I can't recollect to be 100% sure, but likely I 
tested also patch by patch.
Anyway, I have just rechecked.
 Probably it is because this header isn't in use with 
!CONFIG_IOREQ_SERVER since all users are x86/hvm/* and common/ioreq.c
--
Regards,
Oleksandr Tyshchenko
 
 
    
     |