All of lore.kernel.org
 help / color / mirror / Atom feed
From: Akihiko Odaki <akihiko.odaki@daynix.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
	"Alex Williamson" <alex.williamson@redhat.com>,
	"Cédric Le Goater" <clg@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Sriram Yagnaraman" <sriram.yagnaraman@est.tech>,
	"Jason Wang" <jasowang@redhat.com>,
	"Keith Busch" <kbusch@kernel.org>,
	"Klaus Jensen" <its@irrelevant.dk>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [PATCH v4 8/9] pcie_sriov: Do not reset NumVFs after unregistering VFs
Date: Wed, 14 Feb 2024 23:32:11 +0900	[thread overview]
Message-ID: <a20793a9-87b0-4a3d-9032-590502454dd0@daynix.com> (raw)
In-Reply-To: <20240214015322-mutt-send-email-mst@kernel.org>

On 2024/02/14 15:53, Michael S. Tsirkin wrote:
> On Wed, Feb 14, 2024 at 02:13:46PM +0900, Akihiko Odaki wrote:
>> I couldn't find such a behavior specified.
> 
> Is it fixing a bug or just removing unnecessary code?
> Is this guest visible at all?

My intention is just to remove unnecessary code, but it is 
guest-visible. The original behavior causes a problem and it should be 
considered as a bug fix if a guest expects VFs can be restored by 
setting VF Enable after clearing it, but I don't know such an example.

> 
>> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
>> ---
>>   hw/pci/pcie_sriov.c | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/hw/pci/pcie_sriov.c b/hw/pci/pcie_sriov.c
>> index 9d668b8d6c17..410bc090fc58 100644
>> --- a/hw/pci/pcie_sriov.c
>> +++ b/hw/pci/pcie_sriov.c
>> @@ -209,7 +209,6 @@ static void unregister_vfs(PCIDevice *dev)
>>           pci_set_enabled(dev->exp.sriov_pf.vf[i], false);
>>       }
>>       dev->exp.sriov_pf.num_vfs = 0;
>> -    pci_set_word(dev->config + dev->exp.sriov_cap + PCI_SRIOV_NUM_VF, 0);
>>   }
>>   
>>   void pcie_sriov_config_write(PCIDevice *dev, uint32_t address,
>>
>> -- 
>> 2.43.0
> 


  reply	other threads:[~2024-02-14 14:33 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14  5:13 [PATCH v4 0/9] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 1/9] hw/pci: Use -1 as a default value for rombar Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 2/9] hw/pci: Determine if rombar is explicitly enabled Akihiko Odaki
2024-02-14  6:49   ` Michael S. Tsirkin
2024-02-14  5:13 ` [PATCH v4 3/9] vfio: Avoid inspecting option QDict for rombar Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 4/9] hw/qdev: Remove opts member Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 5/9] pcie_sriov: Validate NumVFs Akihiko Odaki
2024-02-14  6:52   ` Michael S. Tsirkin
2024-02-14 14:49     ` Akihiko Odaki
2024-02-14 15:54       ` Michael S. Tsirkin
2024-02-14 16:22         ` Akihiko Odaki
2024-02-14  8:58   ` Michael Tokarev
2024-02-14 14:54     ` Akihiko Odaki
2024-02-14 15:53       ` Michael Tokarev
2024-02-14 15:55         ` Michael S. Tsirkin
2024-02-17 11:32           ` Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 6/9] pcie_sriov: Reuse SR-IOV VF device instances Akihiko Odaki
2024-02-14  7:54   ` Michael S. Tsirkin
2024-02-14 14:44     ` Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 7/9] pcie_sriov: Release VFs failed to realize Akihiko Odaki
2024-02-14  7:54   ` Michael S. Tsirkin
2024-02-14  7:58     ` Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 8/9] pcie_sriov: Do not reset NumVFs after unregistering VFs Akihiko Odaki
2024-02-14  6:53   ` Michael S. Tsirkin
2024-02-14 14:32     ` Akihiko Odaki [this message]
2024-02-14 15:51       ` Michael S. Tsirkin
2024-02-14 16:10         ` Akihiko Odaki
2024-02-14  5:13 ` [PATCH v4 9/9] hw/nvme: Refer to dev->exp.sriov_pf.num_vfs Akihiko Odaki
2024-02-14  7:07   ` Michael S. Tsirkin
2024-02-14 14:09     ` Akihiko Odaki
2024-02-14 15:46       ` Michael S. Tsirkin
2024-02-14 16:07         ` Akihiko Odaki
2024-02-14 16:34           ` Michael S. Tsirkin
2024-02-14 16:51             ` Akihiko Odaki

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=a20793a9-87b0-4a3d-9032-590502454dd0@daynix.com \
    --to=akihiko.odaki@daynix.com \
    --cc=alex.williamson@redhat.com \
    --cc=berrange@redhat.com \
    --cc=clg@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=its@irrelevant.dk \
    --cc=jasowang@redhat.com \
    --cc=kbusch@kernel.org \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-block@nongnu.org \
    --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 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.