From: "Cédric Le Goater" <clg@redhat.com>
To: Akihiko Odaki <akihiko.odaki@daynix.com>,
Sriram Yagnaraman <sriram.yagnaraman@est.tech>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Jason Wang <jasowang@redhat.com>
Subject: Re: [PATCH] igb: Add Function Level Reset to PF and VF
Date: Mon, 29 May 2023 17:07:39 +0200 [thread overview]
Message-ID: <d5c359c5-79fa-dffc-101b-08c0f08f7071@redhat.com> (raw)
In-Reply-To: <5ab583be-8e7a-5636-d14c-f04ecd670894@daynix.com>
On 5/29/23 09:45, Akihiko Odaki wrote:
> On 2023/05/29 16:01, Cédric Le Goater wrote:
>> On 5/29/23 04:45, Akihiko Odaki wrote:
>>> On 2023/05/28 19:50, Sriram Yagnaraman wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Cédric Le Goater <clg@redhat.com>
>>>>> Sent: Friday, 26 May 2023 19:31
>>>>> To: qemu-devel@nongnu.org
>>>>> Cc: Akihiko Odaki <akihiko.odaki@daynix.com>; Sriram Yagnaraman
>>>>> <sriram.yagnaraman@est.tech>; Jason Wang <jasowang@redhat.com>; Cédric
>>>>> Le Goater <clg@redhat.com>
>>>>> Subject: [PATCH] igb: Add Function Level Reset to PF and VF
>>>>>
>>>>> The Intel 82576EB GbE Controller say that the Physical and Virtual Functions
>>>>> support Function Level Reset. Add the capability to each device model.
>>>>>
>>>>> Cc: Akihiko Odaki <akihiko.odaki@daynix.com>
>>>>> Fixes: 3a977deebe6b ("Intrdocue igb device emulation")
>>>>> Signed-off-by: Cédric Le Goater <clg@redhat.com>
>>>>> ---
>>>>> hw/net/igb.c | 3 +++
>>>>> hw/net/igbvf.c | 3 +++
>>>>> 2 files changed, 6 insertions(+)
>>>>>
>>>>> diff --git a/hw/net/igb.c b/hw/net/igb.c index 1c989d767725..08e389338dca
>>>>> 100644
>>>>> --- a/hw/net/igb.c
>>>>> +++ b/hw/net/igb.c
>>>>> @@ -101,6 +101,7 @@ static void igb_write_config(PCIDevice *dev, uint32_t
>>>>> addr,
>>>>>
>>>>> trace_igb_write_config(addr, val, len);
>>>>> pci_default_write_config(dev, addr, val, len);
>>>>> + pcie_cap_flr_write_config(dev, addr, val, len);
>>>>>
>>>>> if (range_covers_byte(addr, len, PCI_COMMAND) &&
>>>>> (dev->config[PCI_COMMAND] & PCI_COMMAND_MASTER)) { @@ -427,6
>>>>> +428,8 @@ static void igb_pci_realize(PCIDevice *pci_dev, Error **errp)
>>>>> }
>>>>>
>>>>> /* PCIe extended capabilities (in order) */
>>>>> + pcie_cap_flr_init(pci_dev);
>>>>> +
>>>>> if (pcie_aer_init(pci_dev, 1, 0x100, 0x40, errp) < 0) {
>>>>> hw_error("Failed to initialize AER capability");
>>>>> }
>>>>> diff --git a/hw/net/igbvf.c b/hw/net/igbvf.c index
>>>>> 284ea611848b..0a58dad06802 100644
>>>>> --- a/hw/net/igbvf.c
>>>>> +++ b/hw/net/igbvf.c
>>>>> @@ -204,6 +204,7 @@ static void igbvf_write_config(PCIDevice *dev,
>>>>> uint32_t addr, uint32_t val, {
>>>>> trace_igbvf_write_config(addr, val, len);
>>>>> pci_default_write_config(dev, addr, val, len);
>>>>> + pcie_cap_flr_write_config(dev, addr, val, len);
>>>>> }
>>>>>
>>>>> static uint64_t igbvf_mmio_read(void *opaque, hwaddr addr, unsigned size)
>>>>> @@ -266,6 +267,8 @@ static void igbvf_pci_realize(PCIDevice *dev, Error
>>>>> **errp)
>>>>> hw_error("Failed to initialize PCIe capability");
>>>>> }
>>>>>
>>>>> + pcie_cap_flr_init(dev);
>>>>
>>>> Sorry for my naive question, and perhaps not related to your patch, IGBVF device class doesn't seem to have any reset functions registered via igbvf_class_init(). So, I am guessing an FLR will not trigger igb_vf_reset(), which is probably what we want.
>>
>> It does through the VTCTRL registers.
>>
>>> You're right. Advertising FLR capability without implementing it can confuse the guest though such probability is quite a low in practice. The reset should be implemented first.
>>
>>
>> I was looking at an issue from a VFIO perspective which does a FLR
>> on a device when pass through. Software and FLR are equivalent for
>> a VF.
>
> They should be equivalent according to the datasheet, but unfortunately current igbvf implementation does nothing when reset. What Sriram proposes is to add code to actually write VTCTRL when FLR occurred and make FLR and software reset equivalent.
> And I think that should be done before this change; you should advertise FLR capability after the reset is actually implemented.
AFAICT, the VFs are reset correctly by the OS when created or probed and
by QEMU when they are passthrough in a nested guest OS (with this patch).
igb_vf_reset() is clearly called in QEMU, see routine e1000_reset_hw_vf()
in Linux.
I don't think a reset op is necessary because VFs are software constructs
but I don't mind really. If so, then, I wouldn't mimic what the OS does
by writing the RST bit in the CTRL register of the VF, I would simply
install igb_vf_reset() as a reset handler.
Thanks,
C.
>
> Regards,
> Akihiko Odaki
>
>>
>> I am not sure a VF needs more really, since it is all controlled
>> by the PF. >
>> C.
>>
>>>
>>>>
>>>>> +
>>>>> if (pcie_aer_init(dev, 1, 0x100, 0x40, errp) < 0) {
>>>>> hw_error("Failed to initialize AER capability");
>>>>> }
>>>>> --
>>>>> 2.40.1
>>>>
>>>
>>
>
next prev parent reply other threads:[~2023-05-29 15:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-26 17:30 [PATCH] igb: Add Function Level Reset to PF and VF Cédric Le Goater
2023-05-28 10:50 ` Sriram Yagnaraman
2023-05-28 11:25 ` Sriram Yagnaraman
2023-05-29 2:45 ` Akihiko Odaki
2023-05-29 7:01 ` Cédric Le Goater
2023-05-29 7:45 ` Akihiko Odaki
2023-05-29 15:07 ` Cédric Le Goater [this message]
2023-05-30 2:02 ` Akihiko Odaki
2023-05-30 8:30 ` Sriram Yagnaraman
2023-05-30 12:30 ` Akihiko Odaki
2023-05-30 15:05 ` Cédric Le Goater
2023-05-30 14:56 ` Cédric Le Goater
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=d5c359c5-79fa-dffc-101b-08c0f08f7071@redhat.com \
--to=clg@redhat.com \
--cc=akihiko.odaki@daynix.com \
--cc=jasowang@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sriram.yagnaraman@est.tech \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).