All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Shmulik Ladkani <shmulik.ladkani@ravellosystems.com>
Cc: Dmitry Fleytman <dmitry@daynix.com>,
	idan.brown@ravellosystems.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/4] vmxnet3: The vmxnet3 device is a PCIE endpoint
Date: Mon, 30 Nov 2015 13:40:44 +0800	[thread overview]
Message-ID: <565BE15C.3030404@redhat.com> (raw)
In-Reply-To: <20151129230755.5463b269@halley>



On 11/30/2015 05:07 AM, Shmulik Ladkani wrote:
> Hi,
>
> On Wed, 25 Nov 2015 16:24:39 +0800 Jason Wang <jasowang@redhat.com> wrote:
>>>>> @@ -2568,6 +2572,7 @@ static void vmxnet3_class_init(ObjectClass *class, void *data)
>>>>>      c->class_id = PCI_CLASS_NETWORK_ETHERNET;
>>>>>      c->subsystem_vendor_id = PCI_VENDOR_ID_VMWARE;
>>>>>      c->subsystem_id = PCI_DEVICE_ID_VMWARE_VMXNET3;
>>>>> +    c->is_express = 1;
>>>> Should we do this conditionally? And how about the migration
>>>> compatibility? Looks like pcie device is using vmstate_pcie_device
>>>> instead of vmstate_pci_device, maybe need a new property bit for this.
>>> (Responding for the entire series)
>>>
>>> Agreed. Will limit these changes for new versions.
>>>
>>> What's your suggested plan?
>>> Does it make sense to have a property for each change (as they are not
>>> necessarily related), or is it too tedious and one property will suffice?
>> Since they are not necessarily related, we'd better use a property for
>> each change.
> Would it make sense if we expose a new vmxnet3 type to differenciate
> pcie vs pci instances of vmxnet3?
>
> Otherwise, migration gets more complicated, as we need to use either
> vmstate_pci_device or vmstate_pcie_device; also, upon vm load, we need
> to preserve the semantics saved (whether the instance was pci or pcie).
>
> I have managed to do so, but is a bit tedious; Exposing a new type seems
> cleaner.

Yes, it's a good idea to have a new type.

Thanks

  reply	other threads:[~2015-11-30  5:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-19 10:52 [Qemu-devel] [PATCH 0/4] vmxnet3: Fine-tune device capabilities Shmulik Ladkani
2015-11-19 10:52 ` [Qemu-devel] [PATCH 1/4] vmxnet3: The vmxnet3 device is a PCIE endpoint Shmulik Ladkani
2015-11-25  2:38   ` Jason Wang
2015-11-25  6:18     ` Shmulik Ladkani
2015-11-25  8:24       ` Jason Wang
2015-11-29 21:07         ` Shmulik Ladkani
2015-11-30  5:40           ` Jason Wang [this message]
2015-11-19 10:52 ` [Qemu-devel] [PATCH 2/4] vmxnet3: Change offsets of PCI capabilities Shmulik Ladkani
2015-11-25  2:42   ` Jason Wang
2015-11-19 10:52 ` [Qemu-devel] [PATCH 3/4] vmxnet3: Change the offset of the MSIX PBA table Shmulik Ladkani
2015-11-25  2:43   ` Jason Wang
2015-11-19 10:52 ` [Qemu-devel] [PATCH 4/4] vmxnet3: Report the Device Serial Number capability Shmulik Ladkani

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=565BE15C.3030404@redhat.com \
    --to=jasowang@redhat.com \
    --cc=dmitry@daynix.com \
    --cc=idan.brown@ravellosystems.com \
    --cc=qemu-devel@nongnu.org \
    --cc=shmulik.ladkani@ravellosystems.com \
    /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.