Re: [XEN PATCH v9 0/5] Support device passthrough when dom0 is PVH on Xen

2024-06-11 Thread Chen, Jiqian
On 2024/6/11 00:07, Jan Beulich wrote:
> On 07.06.2024 10:11, Jiqian Chen wrote:
>> Hi All,
>> This is v9 series to support passthrough when dom0 is PVH
>> v8->v9 changes:
>> * patch#1: Move pcidevs_unlock below write_lock, and remove 
>> "ASSERT(pcidevs_locked());" from vpci_reset_device_state;
>>Add pci_device_state_reset_type to distinguish the reset types.
>> * patch#2: Add a comment above PHYSDEVOP_map_pirq to describe why need this 
>> hypercall.
>>Change "!is_pv_domain(d)" to "is_hvm_domain(d)", and "map.domid 
>> == DOMID_SELF" to "d == current->domian".
>> * patch#3: Remove the check of PHYSDEVOP_setup_gsi, since there is same 
>> checke in below.
> 
> Having looked at patch 3, what check(s) is (are) being talked about here?
> It feels as if to understand this revision log entry, one would still need
> to go back to the earlier version. Yet the purpose of these is that one
> (preferably) wouldn't need to do so.
Sorry, it should be:
patch#3: Remove the check of PHYSDEVOP_setup_gsi, since there is same check in 
below. Although their return values are different, this difference is 
acceptable for the sake of code consistency
 if ( !is_hardware_domain(currd) )
 return -ENOSYS;
 break;
I will change in next version.

> 
> Jan

-- 
Best regards,
Jiqian Chen.


Re: [XEN PATCH v9 0/5] Support device passthrough when dom0 is PVH on Xen

2024-06-10 Thread Jan Beulich
On 07.06.2024 10:11, Jiqian Chen wrote:
> Hi All,
> This is v9 series to support passthrough when dom0 is PVH
> v8->v9 changes:
> * patch#1: Move pcidevs_unlock below write_lock, and remove 
> "ASSERT(pcidevs_locked());" from vpci_reset_device_state;
>Add pci_device_state_reset_type to distinguish the reset types.
> * patch#2: Add a comment above PHYSDEVOP_map_pirq to describe why need this 
> hypercall.
>Change "!is_pv_domain(d)" to "is_hvm_domain(d)", and "map.domid == 
> DOMID_SELF" to "d == current->domian".
> * patch#3: Remove the check of PHYSDEVOP_setup_gsi, since there is same 
> checke in below.

Having looked at patch 3, what check(s) is (are) being talked about here?
It feels as if to understand this revision log entry, one would still need
to go back to the earlier version. Yet the purpose of these is that one
(preferably) wouldn't need to do so.

Jan



[XEN PATCH v9 0/5] Support device passthrough when dom0 is PVH on Xen

2024-06-07 Thread Jiqian Chen
Hi All,
This is v9 series to support passthrough when dom0 is PVH
v8->v9 changes:
* patch#1: Move pcidevs_unlock below write_lock, and remove 
"ASSERT(pcidevs_locked());" from vpci_reset_device_state;
   Add pci_device_state_reset_type to distinguish the reset types.
* patch#2: Add a comment above PHYSDEVOP_map_pirq to describe why need this 
hypercall.
   Change "!is_pv_domain(d)" to "is_hvm_domain(d)", and "map.domid == 
DOMID_SELF" to "d == current->domian".
* patch#3: Remove the check of PHYSDEVOP_setup_gsi, since there is same checke 
in below.
* patch#5: Change the commit message to describe more why we need this new 
hypercall.
   Add comment above "if ( is_pv_domain(current->domain) || 
has_pirq(current->domain) )" to explain why we need this check.
   Add gsi_2_irq to transform gsi to irq, instead of 
considering gsi == irq.
   Add explicit padding to struct xen_domctl_gsi_permission.


Best regards,
Jiqian Chen



v7->v8 changes:
* patch#2: Add the domid check(domid == DOMID_SELF) to prevent self map when 
guest doesn't use pirq.
   That check was missed in the previous version.
* patch#4: Due to changes in the implementation of obtaining gsi in the kernel. 
Change to add a new function
   to get gsi by passing in the sbdf of pci device.
* patch#5: Remove the parameter "is_gsi", when there exist gsi, in 
pci_add_dm_done use a new function
   pci_device_set_gsi to do map_pirq and grant permission. That gets 
more intuitive code logic.


v6->v7 changes:
* patch#4: Due to changes in the implementation of obtaining gsi in the kernel. 
Change to add a new function
   to get gsi from irq, instead of gsi sysfs.
* patch#5: Fix the issue with variable usage, rc->r.


v5->v6 changes:
* patch#1: Add Reviewed-by Stefano and Stewart. Rebase code and change old 
function vpci_remove_device,
   vpci_add_handlers to vpci_deassign_device, vpci_assign_device
* patch#2: Add Reviewed-by Stefano
* patch#3: Remove unnecessary "ASSERT(!has_pirq(currd));"
* patch#4: Fix some coding style issues below directory tools
* patch#5: Modified some variable names and code logic to make code easier to 
be understood, which to use
   gsi by default and be compatible with older kernel versions to 
continue to use irq


v4->v5 changes:
* patch#1: add pci_lock wrap function vpci_reset_device_state
* patch#2: move the check of self map_pirq to physdev.c, and change to check if 
the caller has PIRQ flag, and
   just break for PHYSDEVOP_(un)map_pirq in hvm_physdev_op
* patch#3: return -EOPNOTSUPP instead, and use ASSERT(!has_pirq(currd));
* patch#4: is the patch#5 in v4 because patch#5 in v5 has some dependency on 
it. And add the handling of errno
   and add the Reviewed-by Stefano
* patch#5: is the patch#4 in v4. New implementation to add new hypercall 
XEN_DOMCTL_gsi_permission to grant gsi


v3->v4 changes:
* patch#1: change the comment of PHYSDEVOP_pci_device_state_reset; move 
printings behind pcidevs_unlock
* patch#2: add check to prevent PVH self map
* patch#3: new patch, The implementation of adding PHYSDEVOP_setup_gsi for PVH 
is treated as a separate patch
* patch#4: new patch to solve the map_pirq problem of PVH dom0. use gsi to 
grant irq permission in
   XEN_DOMCTL_irq_permission.
* patch#5: to be compatible with previous kernel versions, when there is no gsi 
sysfs, still use irq
v4 link:
https://lore.kernel.org/xen-devel/20240105070920.350113-1-jiqian.c...@amd.com/T/#t

v2->v3 changes:
* patch#1: move the content out of pci_reset_device_state and delete 
pci_reset_device_state; add
   xsm_resource_setup_pci check for PHYSDEVOP_pci_device_state_reset; 
add description for
   PHYSDEVOP_pci_device_state_reset;
* patch#2: du to changes in the implementation of the second patch on kernel 
side(that it will do setup_gsi and
   map_pirq when assigning a device to passthrough), add 
PHYSDEVOP_setup_gsi for PVH dom0, and we need
   to support self mapping.
* patch#3: du to changes in the implementation of the second patch on kernel 
side(that adds a new sysfs for gsi
   instead of a new syscall), so read gsi number from the sysfs of gsi.
v3 link:
https://lore.kernel.org/xen-devel/20231210164009.1551147-1-jiqian.c...@amd.com/T/#t

v2 link:
https://lore.kernel.org/xen-devel/20231124104136.3263722-1-jiqian.c...@amd.com/T/#t
Below is the description of v2 cover letter:
This series of patches are the v2 of the implementation of passthrough when 
dom0 is PVH on Xen.
We sent the v1 to upstream before, but the v1 had so many problems and we got 
lots of suggestions.
I will introduce all issues that these patches try to fix and the differences 
between v1 and v2.

Issues we encountered:
1. pci_stub failed to write bar for a passthrough device.
Problem: when we run \u201csudo xl pci-assignable-add \u201d to assign a 
device, pci_stub will call