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

Re: [XEN PATCH v8 1/5] xen/vpci: Clear all vpci status of device


  • To: Jürgen Groß <jgross@xxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Date: Fri, 17 May 2024 10:09:45 +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=arcselector9901; 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=VrBNDZm4NVDfTbuhqJBPUVkbLlFN+3+NAlARdffVE5I=; b=erZ+oGsvavOm12AWfMc/zOwC/8r0rtTBJS64mft+xl+EESgzGVrWM1xZjcWVTSS/q0OIkgR8AXRXWGZIHABJM261scTs5g4XwAvcYvVeM1l6CSbsi6YEjcOJ5zD4MgNWDy9PZRaJfzGMePqyFUfAydUBbIBep0Kl+7tfFAc02/6ILZHqjtKycgPWPn/sNeOq4g6J2MkTU+5Uct8mmnKfcXncLt8A6vYsncGEmzHTcDHKAu0du2MZUJvAtCfZL5tIg4ta2TS0xAKX3du8bfo1m62ytsm+Ai6+IaCgbUIk+7H80ZPppuhpZkC12E2K65ei2NEi6VHhHWS1BdKWcELHrw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nf/m7rDMbVVcUcs0LEJZR3B6nGDp5aqSqkZAjYI+n22w+09P7JIyb9hiaCJsPvhWIYF/nwx66KLxtY1zpoDJ3dGIhXwDZAArK7PXkR6MhVSXLvmwDKwuWGD8egOz5SMUG3Q4bgt9QgpMfw15/ifNbUvNUhsx2Z/DjtMiBt3ZHYQPWNx9vdykAxwTJ9LNA++ylNaVAAI+2ex4xmu31PrG7dQXMRVtI2bvO5nLRsPh8c4kEtslwUFtESsNo2fesCMrGkNx8k5ow/9QqNis+XgEkZ9XOBUzIMHHWJORiLtYYXdafSZeQ4MPTWR2mFwIxrz7Ef/N0GM8mX+tiGv71AMZUQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Anthony PERARD <anthony@xxxxxxxxxxxxxx>, "Hildebrand, Stewart" <Stewart.Hildebrand@xxxxxxx>, "Huang, Ray" <Ray.Huang@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Daniel P . Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Delivery-date: Fri, 17 May 2024 10:09:57 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHap3bYcGtlWtrcpEyRLTK5fjq5SLGZ1UMAgAFwSAD//9GPgIAAlWQA//+DzoCAAAPIgIAAhyMA
  • Thread-topic: [XEN PATCH v8 1/5] xen/vpci: Clear all vpci status of device

Hi Juergen:

On 2024/5/17 18:03, Jürgen Groß wrote:
> On 17.05.24 11:50, Jan Beulich wrote:
>> On 17.05.2024 11:28, Chen, Jiqian wrote:
>>> On 2024/5/17 16:20, Jan Beulich wrote:
>>>> On 17.05.2024 10:08, Chen, Jiqian wrote:
>>>>> On 2024/5/16 21:08, Jan Beulich wrote:
>>>>>> On 16.05.2024 11:52, Jiqian Chen wrote:
>>>>>>>   struct physdev_pci_device {
>>>>>>>       /* IN */
>>>>>>>       uint16_t seg;
>>>>>>
>>>>>> Is re-using this struct for this new sub-op sufficient? IOW are all
>>>>>> possible resets equal, and hence it doesn't need specifying what kind of
>>>>>> reset was done? For example, other than FLR most reset variants reset all
>>>>>> functions in one go aiui. Imo that would better require only a single
>>>>>> hypercall, just to avoid possible confusion. It also reads as if FLR 
>>>>>> would
>>>>>> not reset as many registers as other reset variants would.
>>>>> If I understood correctly that you mean in this hypercall it needs to 
>>>>> support resetting both one function and all functions of a slot(dev)?
>>>>> But it can be done for caller to use a cycle to call this reset hypercall 
>>>>> for each slot function.
>>>>
>>>> It could, yes, but since (aiui) there needs to be an indication of the
>>>> kind of reset anyway, we can as well avoid relying on the caller doing
>>>> so (and at the same time simplify what the caller needs to do).
>>> Since the corresponding kernel patch has been merged into linux_next branch
>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20240515&id=b272722511d5e8ae580f01830687b8a6b2717f01,
>>> if it's not very mandatory and necessary, just let the caller handle it 
>>> temporarily.
>>
>> As also mentioned for the other patch having a corresponding kernel one:
>> The kernel patch would imo better not be merged until the new sub-op is
>> actually finalized.
> 
> Oh, sorry to have overlooked that the interfcae change isn't yet committed on
> Xen side.
> 
> I'll drop the patch from my linux-next branch.
Thanks. I will modify my code according to Jan's requirements and send a new 
version soon.

> 
> 
> Juergen
> 

-- 
Best regards,
Jiqian Chen.

 


Rackspace

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