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

Re: [PATCH 2/2] xen/dm: arm: Introduce inject_msi2 DM op


  • To: Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • From: Mykyta Poturai <Mykyta_Poturai@xxxxxxxx>
  • Date: Thu, 20 Mar 2025 14:39:52 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.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=861WXRcE47hjKl69I4CqcqlkijG/GL80BXcMb4HQo5c=; b=o3/ym7trRESD+HEBNdDr4X0mAOtO6YoRtx7LdxQQJtJXI8yQ+sQLJJwubvXT04hmy/VhvEhY581TSSML0nHQVXmtcnXc5AlpTsO95VdU5Z2YdtInibX0bz2K6XfsUXhnnC5DGMZE4hdDxSZpSWvU8cwK2LcTH6bGvvpP/BhACEoaBgCyO2Mg30biAuFZXCex88paxXugwhNtk1qCdBAzNQIG/wf0hUlVcWMXOzOQRfHIZZcTwfRx45GbYW1FgKKfnStX5O10yL4fBhaYAa6kby9lzXZEqE4aHgcr6xRKK6c+qCY3LbLYahPLWxOMEmrCBPuuMR/rJmyV3d2Do6uH7w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=eOldWQ2dxWzoy1mKPltSfJmB/erfk/lsznymOtXjGezxxWswCKpbBeABI8cctIQT2mph9w7u53mabd1PBry6PSiAiyCeoz7cPpEoyrneKK9BiO2q1vOFah40+NNTFki31QHaUFtZCmHSkWpOi/OVvH8RU8Lq0uuHJG+Q8D2krW3OHHRD6yNL2nJuFJaHSISgkV43wN6PW27lV+us7n5JoXXO8IPchThMayNNu2Z1xdxVEk0FmML0/39F8Kh2fbLCG9gr8dZ4csvu6baKp2fIlkBggKrsS8y3VJT/3QHVMqGsfVA5Pv1HylLUJXfrk4csetTBVpKFmxuzY4cW2CoHaA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Juergen Gross <jgross@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Delivery-date: Thu, 20 Mar 2025 14:40:03 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHaRWELmXttIq3ydUeKyfZPAZRMh7DaobyAgqCezQCAABD4AIAAN9aAgAAPTYCAAWsXAIAACOmAgACHWACAALUgAIAAXkqAgAAZt4A=
  • Thread-topic: [PATCH 2/2] xen/dm: arm: Introduce inject_msi2 DM op

On 20.03.25 15:07, Oleksandr Tyshchenko wrote:
>>> If I got correctly what is wrote in current thread (and in RFC version
>>> where it was an attempt to create just Arm64's counterpart of
>>> XEN_DMOP_inject_msi), my understanding (maybe not precise/correct, since
>>> I am not quite familiar with x86 details) that we would need something
>>> like that:
>>>
>>>
>>> /*
>>>    * XEN_DMOP_inject_msi2: An enhanced version of the sub-ob to 
>>> inject an MSI
>>>    *                       for an emulated device, which allows 
>>> specifying
>>>    *                       the ID of the device triggering the MSI
>>> (source ID).
>>>    *
>>>    * The source ID is specified by a pair of <segment> and <source_id>.
>>>    * If <flags> does not contain XEN_DMOP_MSI_SOURCE_ID_VALID then 
>>> source ID
>>>    * is invalid and should be ignored.
>>>    */
>>> #define XEN_DMOP_inject_msi 21
>>>
>>> struct xen_dm_op_inject_msi2 {
>>>        /* IN - MSI data */
>>>        uint32_t data;
>>>        /* IN - next two fields form an ID of the device triggering 
>>> the MSI */
>>>        uint16_t segment; /* The segment number */
>>>        uint16_t source_id; /* The source ID that is local to segment 
>>> (PCI
>>> BDF) */
>>>        /* IN - types of source ID */
>>>        uint32_t flags;
>>> #define XEN_DMOP_MSI_SOURCE_ID_VALID (1u << 0)
>>>        uint32_t pad;
>>>        /* IN - MSI address */
>>>        uint64_aligned_t addr;
>>> };
>>>
>>>
>>> This is arch agnostic sub-op without the (obvious) specifics of the
>>> underlying MSI controller. The sub-ob, I hope, will be suitable on both
>>> Arm64 soon (segment + source_id provide vSBDF, then it will possible to
>>> locate vITS and devid) and on x86 in future (for the vIOMMU needs).
>>>
>>> Would you be ok with that in general? Please share you opinion.
>>
>> Yes, this looks plausible.
> 
> Jan, thanks
> 
> 
>   In the context of things like VMD (using
>> software established segment numbers wider than 16 bits) I wonder
>> though whether we wouldn't better make segment and source ID 32-bit
>> fields from the beginning.
> 
> Keeping in mind that dm_op hypercall is stable and segment can be >= 
> 0x10000, probably yes, makes sense to use 32-bit from the very beginning.
> 
> 
>   Out-of-range values would of course need
>> rejecting then.
> 
> yes, sure
> 
> ***
> 
> Mykyta, are you ok with the proposed adjustments to the sub-op structure?
> 
>>
>> Jan

Yes, seems fine for me. I will use it in the next version.

-- 
Mykyta

 


Rackspace

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