qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>
Cc: liang yan <lyan@suse.com>,
	Jailhouse <jailhouse-dev@googlegroups.com>,
	Claudio Fontana <claudio.fontana@gmail.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Markus Armbruster <armbru@redhat.com>,
	Hannes Reinecke <hare@suse.de>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [RFC][PATCH 2/3] docs/specs: Add specification of ivshmem device revision 2
Date: Mon, 11 Nov 2019 16:42:52 +0100	[thread overview]
Message-ID: <129c527c-1e61-8c0c-3ca1-fe93e26c8bd2@siemens.com> (raw)
In-Reply-To: <20191111152743.GM814211@redhat.com>

On 11.11.19 16:27, Daniel P. Berrangé wrote:
> On Mon, Nov 11, 2019 at 10:08:20AM -0500, Michael S. Tsirkin wrote:
>> On Mon, Nov 11, 2019 at 02:59:07PM +0100, Jan Kiszka wrote:
>>> On 11.11.19 14:45, Michael S. Tsirkin wrote:
>>>> On Mon, Nov 11, 2019 at 01:57:11PM +0100, Jan Kiszka wrote:
>>>>> +| Offset | Register               | Content                                              |
>>>>> +|-------:|:-----------------------|:-----------------------------------------------------|
>>>>> +|    00h | Vendor ID              | 1AF4h                                                |
>>>>> +|    02h | Device ID              | 1110h                                                |
>>>>
>>>> Given it's a virtio vendor ID, please reserve a device ID
>>>> with the virtio TC.
>>>
>>> Yeah, QEMU's IVSHMEM was always using that. I'm happy to make this finally
>>> official.
>>>
>>
>> And I guess we will just mark it reserved or something right?
>> Since at least IVSHMEM 1 isn't a virtio device.
>> And will you be reusing same ID for IVSHMEM 2 or a new one?
> 
> 1110h isn't under either of the virtio PCI device ID allowed ranges
> according to the spec:
> 
>    "Any PCI device with PCI Vendor ID 0x1AF4, and PCI Device
>     ID 0x1000 through 0x107F inclusive is a virtio device.
>     ...
>     Additionally, devices MAY utilize a Transitional PCI Device
>     ID range, 0x1000 to 0x103F depending on the device type. "
> 
> So there's no need to reserve 0x1110h from the virtio spec POV.

Indeed.

> 
> I have, however, ensured it is assigned to ivshmem from POV of
> Red Hat's own internal tracking of allocated device IDs, under
> its vendor ID.
> 
> If ivshmem 2 is now a virtio device, then it is a good thing that
> it will get a new/different PCI device ID, to show that it is not
> compatible with the old device impl.

At this stage, it is just a PCI device that may be used in combination 
with virtio (stacked on top), but it is not designed like a normal 
virtio (PCI) device. That's because it lacks many properties of regular 
virtio devices, like queues.

So, if such a device could be come part of the virtio spec, it would be 
separate from the rest, and having an ID from the regular range would 
likely not be helpful in this regard.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


  reply	other threads:[~2019-11-11 15:44 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-11 12:57 [RFC][PATCH 0/3] IVSHMEM version 2 device for QEMU Jan Kiszka
2019-11-11 12:57 ` [RFC][PATCH 1/3] hw/misc: Add implementation of ivshmem revision 2 device Jan Kiszka
2019-11-11 12:57 ` [RFC][PATCH 2/3] docs/specs: Add specification of ivshmem device revision 2 Jan Kiszka
2019-11-11 13:45   ` Michael S. Tsirkin
2019-11-11 13:59     ` Jan Kiszka
2019-11-11 15:08       ` Michael S. Tsirkin
2019-11-11 15:27         ` Daniel P. Berrangé
2019-11-11 15:42           ` Jan Kiszka [this message]
2019-11-11 16:14             ` Michael S. Tsirkin
2019-11-11 16:25               ` Jan Kiszka
2019-11-11 16:11           ` Michael S. Tsirkin
2019-11-11 16:38             ` Jan Kiszka
2019-11-12  8:04               ` Michael S. Tsirkin
2019-11-20 18:15                 ` Jan Kiszka
2019-12-05 11:14   ` Markus Armbruster
2019-12-05 21:29     ` Jan Kiszka
2019-12-06 10:08       ` Markus Armbruster
2019-11-11 12:57 ` [RFC][PATCH 3/3] contrib: Add server for ivshmem " Jan Kiszka
2019-11-12  0:56 ` [RFC][PATCH 0/3] IVSHMEM version 2 device for QEMU no-reply
2019-11-27 15:28 ` Liang Yan
2019-11-27 17:19   ` Jan Kiszka
2019-12-02  6:16     ` Jan Kiszka
     [not found]       ` <877b0cd9-d1c5-00c9-c4b6-567c67740962@suse.com>
2019-12-03  7:14         ` Jan Kiszka

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=129c527c-1e61-8c0c-3ca1-fe93e26c8bd2@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=claudio.fontana@gmail.com \
    --cc=hare@suse.de \
    --cc=jailhouse-dev@googlegroups.com \
    --cc=lyan@suse.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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 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).