virtio-dev.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	virtio-dev@lists.oasis-open.org,
	 "Michael S. Tsirkin" <mst@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	stratos-dev@op-lists.linaro.org,
	 Erik Schilling <erik.schilling@linaro.org>,
	 Manos Pitsidianakis <manos.pitsidianakis@linaro.org>,
	 Mathieu Poirier <mathieu.poirier@linaro.org>,
	Bill Mills <bill.mills@linaro.org>
Subject: [virtio-dev] Re: [PATCH] virtio-transport: Clarify requirements
Date: Mon, 18 Dec 2023 14:19:43 +0000	[thread overview]
Message-ID: <877clb61a8.fsf@draig.linaro.org> (raw)
In-Reply-To: <87r0jjfw21.fsf@redhat.com> (Cornelia Huck's message of "Mon, 18 Dec 2023 15:02:30 +0100")

Cornelia Huck <cohuck@redhat.com> writes:

> On Wed, Dec 06 2023, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
>> On 05-12-23, 14:18, Cornelia Huck wrote:
>>> On Tue, Dec 05 2023, Viresh Kumar <viresh.kumar@linaro.org> wrote:
<snip>
>>
>> - The transport MUST provide a mechanism for the device and the driver
>>   to notify each other, for example about availability of a buffer on
>>   the virtqueue.
>
> Probably a mechanism for the device to notify the driver, and a
> mechanism for the driver to notify the device? They can be different, as
> long both of them are present.
>
>>
>> - The transport SHOULD provide a mechanism for the driver to initiate
>>   a reset of the virtqueues and device.
>
> Can we mandate a mechanism for a device reset? Reset of virtqueues needs
> to be optional, I'm not sure whether a SHOULD would be appropriate for
> that (or maybe we should finally come up with something for ccw ;)
>
> Other things that probably should be mandatory:
>
> - A way for the driver to change the device status. Reading it would
>   probably be a strong SHOULD.
> - A way to implement config space. (For example, channel devices don't
>   have a config space or anything similar enough to repurpose, so I had
>   to invent a mechanism for ccw... maybe future transports will be in
>   the same boat.)

I think Bill has run into problems with config space on OpenAMP setups
where there can be no specific trapping between domains making it hard
to manage a config space where both sides might want to make updates. I
guess the original MMIO transport gets away with it because config space
is always in the trap-and-emulate address space in a normal VM/emulation
situation.

Bill,

Is the plan to introduce a new transport that manages config in a
different way?

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2023-12-18 14:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-05 10:20 [virtio-dev] [PATCH] virtio-transport: Clarify requirements Viresh Kumar
2023-12-05 13:18 ` [virtio-dev] " Cornelia Huck
2023-12-05 13:54   ` Alex Bennée
2023-12-18 13:12     ` Cornelia Huck
2023-12-18 14:09       ` Alex Bennée
2023-12-20 12:43         ` Cornelia Huck
2023-12-06  9:43   ` Viresh Kumar
2023-12-18  7:00     ` Viresh Kumar
2023-12-18 14:02     ` Cornelia Huck
2023-12-18 14:19       ` Alex Bennée [this message]
     [not found]         ` <8b278f33-4702-4a7c-bb80-e11c316234c4@linaro.org>
2023-12-20 13:50           ` Cornelia Huck
2024-01-29 10:35       ` Viresh Kumar
2024-01-29 16:22         ` Cornelia Huck

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=877clb61a8.fsf@draig.linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=bill.mills@linaro.org \
    --cc=cohuck@redhat.com \
    --cc=erik.schilling@linaro.org \
    --cc=manos.pitsidianakis@linaro.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=mst@redhat.com \
    --cc=stratos-dev@op-lists.linaro.org \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    --cc=virtio-dev@lists.oasis-open.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 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).