From: "Chen, Jiqian" <Jiqian.Chen@amd.com>
To: Jason Wang <jasowang@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Huang, Ray" <Ray.Huang@amd.com>,
"Chen, Jiqian" <Jiqian.Chen@amd.com>
Subject: Re: [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit
Date: Tue, 2 Apr 2024 02:56:14 +0000 [thread overview]
Message-ID: <BL1PR12MB584947CF6BFAEBA2CB4E904EE73E2@BL1PR12MB5849.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CACGkMEvNjeYSRQRdcSz4=Cg-DvqNWhD6w9H75PFiqdcQPH+Xww@mail.gmail.com>
On 2024/3/29 18:38, Jason Wang wrote:
> On Fri, Mar 29, 2024 at 4:00 PM Chen, Jiqian <Jiqian.Chen@amd.com> wrote:
>>
>> On 2024/3/29 15:20, Jason Wang wrote:
>>> On Fri, Mar 29, 2024 at 3:07 PM Chen, Jiqian <Jiqian.Chen@amd.com> wrote:
>>>>
>>>> On 2024/3/28 20:36, Michael S. Tsirkin wrote:
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> static void virtio_pci_bus_reset_hold(Object *obj)
>>>>>>>> {
>>>>>>>> PCIDevice *dev = PCI_DEVICE(obj);
>>>>>>>> DeviceState *qdev = DEVICE(obj);
>>>>>>>>
>>>>>>>> + if (virtio_pci_no_soft_reset(dev)) {
>>>>>>>> + return;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> virtio_pci_reset(qdev);
>>>>>>>>
>>>>>>>> if (pci_is_express(dev)) {
>>>>>>>> @@ -2484,6 +2511,8 @@ static Property virtio_pci_properties[] = {
>>>>>>>> VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT, true),
>>>>>>>> DEFINE_PROP_BIT("x-pcie-pm-init", VirtIOPCIProxy, flags,
>>>>>>>> VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
>>>>>>>> + DEFINE_PROP_BIT("x-pcie-pm-no-soft-reset", VirtIOPCIProxy, flags,
>>>>>>>> + VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT, false),
>>>
>>> Why does it come with an x prefix?
>> Sorry, it's my misunderstanding of this prefix, if No_Soft_Reset doesn't need this prefix, I will delete it in next version.
>> Does x prefix means compat machinery? Or other meanings?
>>
>>>
>>>>>>>> DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
>>>>>>>> VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
>>>>>>>> DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
>>>>>>>
>>>>>>> I am a bit confused about this part.
>>>>>>> Do you want to make this software controllable?
>>>>>> Yes, because even the real hardware, this bit is not always set.
>>>
>>> We are talking about emulated devices here.
>> Yes, I just gave an example. It actually this bit is not always set. What's your opinion about when to set this bit or which virtio-device should set this bit?
>
> If the implementation of Qemu is correct, we should set it unless we
> need compatibility.
Ok, I will set it default to true in next version.
If we need compatibility, what's your opinion about which machine types should we compatible with? Does the same as x-pcie-pm-init?
>
>>
>>>
>>>>>
>>>>> So which virtio devices should and which should not set this bit?
>>>> This depends on the scenario the virtio-device is used, if we want to trigger an internal soft reset for the virtio-device during S3, this bit shouldn't be set.
>>>
>>> If the device doesn't need reset, why bother the driver for this?
>> I don't know what you mean.
>> If the device doesn't need reset, we can config true to set this bit, then on the driver side, driver finds this bit is set, then driver will not trigger a soft reset.
>
> I mean if the device can suspend without reset, we don't need to
> bother the driver to save and load states.
>
>>
>>>
>>> Btw, no_soft_reset is insufficient for some cases,
>> May I know which cases?
>>
>>> there's a proposal for the virtio-spec. I think we need to wait until it is done.
>> Can you share the proposal?
>
> See this
>
> https://lore.kernel.org/all/20240227015345.3614965-1-stevensd@chromium.org/T/
I looked the detail of this proposal.
What the proposal does is to add a new status to trigger device to suspend/resume.
But this patch is to add No_Soft_Reset bit, it decides if the device should be reset. This patch doesn't depend on the proposal.
If you mean that the proposal says "A device MUST maintain its state while suspended", I think it needs new patch to implement it after the proposal is done.
>
> Thanks
>
>>
>>>
>>>> In my use case on my environment, I don't want to reset virtio-gpu during S3,
>>>> because once the display resources are destroyed, there are not enough information to re-create them, so this bit should be set.
>>>> Making this bit software controllable is convenient for users to take their own choices.
>>>
>>> Thanks
>>>
>>>>
>>>>>
>>>>>>> Or should this be set to true by default and then
>>>>>>> changed to false for old machine types?
>>>>>> How can I do so?
>>>>>> Do you mean set this to true by default, and if old machine types don't need this bit, they can pass false config to qemu when running qemu?
>>>>>
>>>>> No, you would use compat machinery. See how is x-pcie-flr-init handled.
>>>>>
>>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Jiqian Chen.
>>>
>>
>> --
>> Best regards,
>> Jiqian Chen.
>
--
Best regards,
Jiqian Chen.
next prev parent reply other threads:[~2024-04-02 3:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-28 10:39 [RFC QEMU PATCH v8 0/1] S3 support Jiqian Chen
2024-03-28 10:39 ` [RFC QEMU PATCH v8 1/2] virtio-pci: only reset pm state during resetting Jiqian Chen
2024-03-28 10:39 ` [RFC QEMU PATCH v8 2/2] virtio-pci: implement No_Soft_Reset bit Jiqian Chen
2024-03-28 10:57 ` Michael S. Tsirkin
2024-03-28 11:08 ` Chen, Jiqian
2024-03-28 12:36 ` Michael S. Tsirkin
2024-03-29 7:00 ` Chen, Jiqian
2024-03-29 7:20 ` Jason Wang
2024-03-29 8:00 ` Chen, Jiqian
2024-03-29 10:38 ` Jason Wang
2024-04-02 2:56 ` Chen, Jiqian [this message]
2024-03-29 10:44 ` Michael S. Tsirkin
2024-04-02 3:03 ` Chen, Jiqian
2024-04-07 3:20 ` Jason Wang
2024-04-07 11:49 ` Michael S. Tsirkin
2024-04-08 4:56 ` Jason Wang
2024-04-12 6:10 ` Chen, Jiqian
2024-04-12 6:04 ` Chen, Jiqian
2024-04-12 6:41 ` Jason Wang
2024-04-12 6:49 ` Chen, Jiqian
2024-04-12 5:59 ` Chen, Jiqian
2024-04-12 6:42 ` Jason Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BL1PR12MB584947CF6BFAEBA2CB4E904EE73E2@BL1PR12MB5849.namprd12.prod.outlook.com \
--to=jiqian.chen@amd.com \
--cc=Ray.Huang@amd.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.