On Mon, Oct 11 2021, Parav Pandit wrote:
>> From: Michael S. Tsirkin
>> Sent: Saturday, October 9, 2021 4:39 AM
>>
>> On Fri, Oct 08, 2021 at 01:23:52PM +, Parav Pandit wrote:
>> >
>> >
>> > > From: Michael S. Tsirkin
>> > > Sent: Friday, October 8, 2021 6:27 PM
>> >
>> > > > 2. A sriov
m to be affected.
>
> Long term the right thing to do is to fix the hypervisors.
>
> Cc: #v4.11
> Signed-off-by: Halil Pasic
> Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config
> space")
> Fixes: fe36cbe0671e ("virtio_net: clear MTU whe
m to be affected.
>
> Long term the right thing to do is to fix the hypervisors.
>
> Cc: #v4.11
> Signed-off-by: Halil Pasic
> Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config
> space")
> Fixes: fe36cbe0671e ("virtio_net: clear MTU whe
gt; @@ -239,6 +239,17 @@ static int virtio_dev_probe(struct device *_d)
>> >driver_features_legacy = driver_features;
>> >}
>> >
>> > + /*
>> > + * Some devices detect legacy solely via F_VERSION_1. Write
>> > + * F_VERSION_1 to force LE config space accesses before
>> > FEATURES_OK for
>> > + * these when needed.
>> > + */
>> > + if (drv->validate && !virtio_legacy_is_little_endian()
>> > +&& device_features &
>> > BIT_ULL(VIRTIO_F_VERSION_1)) {
>> > + dev->features = BIT_ULL(VIRTIO_F_VERSION_1);
>> > + dev->config->finalize_features(dev);
>> > + }
>> > +
>> >if (device_features & (1ULL << VIRTIO_F_VERSION_1))
>> >dev->features = driver_features & device_features;
>> >else
>> >
>> > base-commit: 60a9483534ed0d99090a2ee1d4bb0b8179195f51
FWIW, with the amends:
Reviewed-by: Cornelia Huck
gt; @@ -239,6 +239,17 @@ static int virtio_dev_probe(struct device *_d)
>> >driver_features_legacy = driver_features;
>> >}
>> >
>> > + /*
>> > + * Some devices detect legacy solely via F_VERSION_1. Write
>> > + * F_
On Fri, Oct 08 2021, "Michael S. Tsirkin" wrote:
> On Fri, Oct 08, 2021 at 10:59:02AM +, Parav Pandit wrote:
>> It may be even a pre-boot environment where 100msec or 10msec may be too
>> short interval as other extreme of VM boot time example.
>
> I don't really know what this means. We
On Thu, Oct 07 2021, Parav Pandit wrote:
>> From: Cornelia Huck
>> Sent: Thursday, October 7, 2021 9:41 PM
>> On Thu, Oct 07 2021, Parav Pandit wrote:
>>
>> >> From: Michael S. Tsirkin
>> >> Sent: Thursday, October 7, 2021 2:23 AM On Wed, Oct
On Thu, Oct 07 2021, Halil Pasic wrote:
> On Thu, 07 Oct 2021 17:25:52 +0200
> Cornelia Huck wrote:
>
>> On Thu, Oct 07 2021, Halil Pasic wrote:
>>
>> > On Thu, 07 Oct 2021 13:52:24 +0200
>> > Cornelia Huck wrote:
>> >
On Thu, Oct 07 2021, Parav Pandit wrote:
>> From: Michael S. Tsirkin
>> Sent: Thursday, October 7, 2021 2:23 AM
>> On Wed, Oct 06, 2021 at 04:11:19PM +, Parav Pandit wrote:
>> >
>> > > From: Michael S. Tsirkin
>> > > Sent: Wednesday, October 6, 2021 8:52 PM
>> > > second, I don't see a
On Thu, Oct 07 2021, Halil Pasic wrote:
> On Thu, 07 Oct 2021 17:25:52 +0200
> Cornelia Huck wrote:
>
>> On Thu, Oct 07 2021, Halil Pasic wrote:
>>
>> > On Thu, 07 Oct 2021 13:52:24 +0200
>> > Cornelia Huck wrote:
>> >
On Thu, Oct 07 2021, Halil Pasic wrote:
> On Thu, 07 Oct 2021 13:52:24 +0200
> Cornelia Huck wrote:
>
>> On Wed, Oct 06 2021, Halil Pasic wrote:
>>
>> > The virtio specification virtio-v1.1-cs01 states: Transitional devices
>> > MUST detect Legacy drive
On Thu, Oct 07 2021, Halil Pasic wrote:
> On Thu, 07 Oct 2021 13:52:24 +0200
> Cornelia Huck wrote:
>
>> On Wed, Oct 06 2021, Halil Pasic wrote:
>>
>> > The virtio specification virtio-v1.1-cs01 states: Transitional devices
>> > MUST detect Legacy drive
On Wed, Oct 06 2021, Halil Pasic wrote:
> The virtio specification virtio-v1.1-cs01 states: Transitional devices
> MUST detect Legacy drivers by detecting that VIRTIO_F_VERSION_1 has not
> been acknowledged by the driver. This is exactly what QEMU as of 6.1
> has done relying solely on
On Wed, Oct 06 2021, Halil Pasic wrote:
> The virtio specification virtio-v1.1-cs01 states: Transitional devices
> MUST detect Legacy drivers by detecting that VIRTIO_F_VERSION_1 has not
> been acknowledged by the driver. This is exactly what QEMU as of 6.1
> has done relying solely on
On Wed, Oct 06 2021, Jean-Philippe Brucker wrote:
> It looks like commit 356aeeb40d7a ("content: add vendor specific cfg
> type") had a merge issue. It includes the device normative paragraph for
> Shared memory capability, which was already added right above it by
> commit 855ad7af2bd6 ("shared
On Wed, Oct 06 2021, Jean-Philippe Brucker wrote:
> It looks like commit 356aeeb40d7a ("content: add vendor specific cfg
> type") had a merge issue. It includes the device normative paragraph for
> Shared memory capability, which was already added right above it by
> commit 855ad7af2bd6 ("shared
On Fri, Aug 06 2021, Enrico Granata wrote:
> Hi folks,
> I am back from my leave of absence, so thank you everyone for your patience
>
> This proposal has been outstanding for a while and didn't seem to
> receive pushback, especially compared to the initial proposal
>
> Would it be the right
On Fri, Aug 06 2021, Enrico Granata wrote:
> Hi folks,
> I am back from my leave of absence, so thank you everyone for your patience
>
> This proposal has been outstanding for a while and didn't seem to
> receive pushback, especially compared to the initial proposal
>
> Would it be the right
On Wed, Oct 06 2021, Pankaj Gupta wrote:
>> >> > +\subsubsection{ Workload specific mapping}\label{sec:Device Types /
>> >> > PMEM Device / Possible Security Implications / Countermeasures /
>> >> > Workload}
>> >> > +For SHARED mappings, for the workload is a single application inside
>> >> >
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 05:50:44PM +0200, Cornelia Huck wrote:
>> On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
>>
>> > On Mon, Oct 04, 2021 at 04:33:21PM +0200, Cornelia Huck wrote:
>> &
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 05:50:44PM +0200, Cornelia Huck wrote:
>> On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
>>
>> > On Mon, Oct 04, 2021 at 04:33:21PM +0200, Cornelia Huck wrote:
>> &
rav Pandit
> Reviewed-by: Max Gurtovoy
>
> ---
> changelog:
> v0->v1:
> - v0: https://lists.oasis-open.org/archives/virtio-dev/202109/msg00133.html
> - Addressed below comments from Cornelia Huck
> - renamed VIRTIO_F_DEV_RESET_TO to VIRTIO_F_DEV_RESET_TIMEOUT
> - rem
On Wed, Oct 06 2021, Pankaj Gupta wrote:
>> > +\subsubsection{ Workload specific mapping}\label{sec:Device Types / PMEM
>> > Device / Possible Security Implications / Countermeasures / Workload}
>> > +For SHARED mappings, for the workload is a single application inside
>> > +the driver and
On Wed, Oct 06 2021, Pankaj Gupta wrote:
> Posting virtio specification for virtio pmem device. Virtio pmem is a
> paravirtualized device which allows the guest to bypass page cache.
> Virtio pmem kernel driver is merged in Upstream Kernel 5.3. Also, Qemu
> device is merged in Qemu 4.1.
>
>
On Tue, Oct 05 2021, "Michael S. Tsirkin" wrote:
> On Tue, Oct 05, 2021 at 06:57:50PM +0200, Cornelia Huck wrote:
>> On Thu, Sep 30 2021, Jean-Philippe Brucker wrote:
>> > \item[VIRTIO_IOMMU_F_BYPASS (3)]
>> > - When not attached to a domain, endpoint
On Thu, Sep 30 2021, Jean-Philippe Brucker wrote:
> The VIRTIO_IOMMU_F_BYPASS feature is awkward to use and incomplete.
> Although it is implemented by QEMU, it is not supported by any driver as
> far as I know. Replace it with a new VIRTIO_IOMMU_F_BYPASS_CONFIG
> feature. The old feature bit is
On Tue, Oct 05 2021, Halil Pasic wrote:
> On Tue, 05 Oct 2021 13:13:31 +0200
> Cornelia Huck wrote:
>> Or am I misunderstanding what you're getting at?
>>
>
> Probably. I'm talking about pre- "do transport specific legacy detection
> in the device inst
On Tue, Oct 05 2021, "Michael S. Tsirkin" wrote:
> On Tue, Oct 05, 2021 at 01:17:51PM +0200, Halil Pasic wrote:
>> On Mon, 4 Oct 2021 16:01:12 -0400
>> "Michael S. Tsirkin" wrote:
>>
>> > >
>> > > Ok, so what about something like
>> > >
>> > > "If FEATURES_OK is not set, the driver MAY
On Tue, Oct 05 2021, Halil Pasic wrote:
> On Tue, 05 Oct 2021 13:13:31 +0200
> Cornelia Huck wrote:
>> Or am I misunderstanding what you're getting at?
>>
>
> Probably. I'm talking about pre- "do transport specific legacy detection
> in the device inst
On Tue, Oct 05 2021, "Michael S. Tsirkin" wrote:
> On Tue, Oct 05, 2021 at 01:17:51PM +0200, Halil Pasic wrote:
>> On Mon, 4 Oct 2021 16:01:12 -0400
>> "Michael S. Tsirkin" wrote:
>>
>> > >
>> > > Ok, so what about something like
>> > >
>> > > "If FEATURES_OK is not set, the driver MAY
On Tue, Oct 05 2021, "Michael S. Tsirkin" wrote:
> On Tue, Oct 05, 2021 at 01:17:51PM +0200, Halil Pasic wrote:
>> On Mon, 4 Oct 2021 16:01:12 -0400
>> "Michael S. Tsirkin" wrote:
>>
>> > >
>> > > Ok, so what about something like
>> > >
>> > > "If FEATURES_OK is not set, the driver MAY
On Tue, Oct 05 2021, Halil Pasic wrote:
> On Mon, 4 Oct 2021 05:07:13 -0400
> "Michael S. Tsirkin" wrote:
>> Well we established that we can know. Here's an alternative explanation:
>
>
> I thin we established how this should be in the future, where a transport
> specific mechanism is used to
On Tue, Oct 05 2021, Halil Pasic wrote:
> On Mon, 4 Oct 2021 05:07:13 -0400
> "Michael S. Tsirkin" wrote:
>> Well we established that we can know. Here's an alternative explanation:
>
>
> I thin we established how this should be in the future, where a transport
> specific mechanism is used to
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 04:23:23AM +0200, Halil Pasic wrote:
>> --8<-
>>
>> From: Halil Pasic
>> Date: Thu, 30 Sep 2021 02:38:47 +0200
>> Subject: [PATCH] virtio: write back feature VERSION_1 before
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 04:23:23AM +0200, Halil Pasic wrote:
>> --8<-
>>
>> From: Halil Pasic
>> Date: Thu, 30 Sep 2021 02:38:47 +0200
>> Subject: [PATCH] virtio: write back feature VERSION_1 before
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 05:45:06PM +0200, Cornelia Huck wrote:
>> On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
>>
>> > On Mon, Oct 04, 2021 at 04:27:23PM +0200, Cornelia Huck wrote:
>> &
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 05:45:06PM +0200, Cornelia Huck wrote:
>> On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
>>
>> > On Mon, Oct 04, 2021 at 04:27:23PM +0200, Cornelia Huck wrote:
>> &
On Tue, Oct 05 2021, Parav Pandit wrote:
>> From: Cornelia Huck
>> Sent: Monday, October 4, 2021 9:09 PM
>
>
>> On Fri, Oct 01 2021, Parav Pandit wrote:
>>
>> >> From: Cornelia Huck
>> >> Sent: Friday, October 1, 2021 5:31 P
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 04:33:21PM +0200, Cornelia Huck wrote:
>> On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
>>
>> > On Mon, Oct 04, 2021 at 02:19:55PM +0200, Cornelia Huck wrote:
>> >
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 04:33:21PM +0200, Cornelia Huck wrote:
>> On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
>>
>> > On Mon, Oct 04, 2021 at 02:19:55PM +0200, Cornelia Huck wrote:
>> >
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 04:27:23PM +0200, Cornelia Huck wrote:
>> On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
>>
>> > On Mon, Oct 04, 2021 at 02:01:14PM +0200, Cornelia Huck wrote:
>> &
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 04:27:23PM +0200, Cornelia Huck wrote:
>> On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
>>
>> > On Mon, Oct 04, 2021 at 02:01:14PM +0200, Cornelia Huck wrote:
>> &
On Fri, Oct 01 2021, Parav Pandit wrote:
>> From: Cornelia Huck
>> Sent: Friday, October 1, 2021 5:31 PM
>>
>> On Thu, Sep 30 2021, Parav Pandit wrote:
>>
> [..]
>
>> > +Once the driver initiates a reset, the device may not be able to
>> &g
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 02:19:55PM +0200, Cornelia Huck wrote:
>>
>> [cc:qemu-devel]
>>
>> On Sat, Oct 02 2021, "Michael S. Tsirkin" wrote:
>>
>> > On Fri, Oct 01, 2021 at 09:21:
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 02:19:55PM +0200, Cornelia Huck wrote:
>>
>> [cc:qemu-devel]
>>
>> On Sat, Oct 02 2021, "Michael S. Tsirkin" wrote:
>>
>> > On Fri, Oct 01, 2021 at 09:21:
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 02:01:14PM +0200, Cornelia Huck wrote:
>> On Sun, Oct 03 2021, "Michael S. Tsirkin" wrote:
>> > @@ -160,6 +163,33 @@ \subsection{Legacy Interface: A Note on Feature
>>
On Mon, Oct 04 2021, "Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 02:01:14PM +0200, Cornelia Huck wrote:
>> On Sun, Oct 03 2021, "Michael S. Tsirkin" wrote:
>> > @@ -160,6 +163,33 @@ \subsection{Legacy Interface: A Note on Feature
>>
[cc:qemu-devel]
On Sat, Oct 02 2021, "Michael S. Tsirkin" wrote:
> On Fri, Oct 01, 2021 at 09:21:25AM +0200, Halil Pasic wrote:
>> On Thu, 30 Sep 2021 07:12:21 -0400
>> "Michael S. Tsirkin" wrote:
>>
>> > On Thu, Sep 30, 2021 at 03:20:49AM +0200, Halil Pasic wrote:
>> > > This patch fixes a
[cc:qemu-devel]
On Sat, Oct 02 2021, "Michael S. Tsirkin" wrote:
> On Fri, Oct 01, 2021 at 09:21:25AM +0200, Halil Pasic wrote:
>> On Thu, 30 Sep 2021 07:12:21 -0400
>> "Michael S. Tsirkin" wrote:
>>
>> > On Thu, Sep 30, 2021 at 03:20:49AM +0200, Halil Pasic wrote:
>> > > This patch fixes a
On Sun, Oct 03 2021, "Michael S. Tsirkin" wrote:
> Sent too early. So here's what I propose. Could you pls take a look
> and if you like this, post a ccw section?
We have not talked about the mmio transport so far, but I guess it
should be fine as legacy and standard are separated.
> There's
On Sun, Oct 03 2021, "Michael S. Tsirkin" wrote:
> Sent too early. So here's what I propose. Could you pls take a look
> and if you like this, post a ccw section?
We have not talked about the mmio transport so far, but I guess it
should be fine as legacy and standard are separated.
> There's
On Thu, Sep 30 2021, Jean-Philippe Brucker wrote:
> It looks like commit 356aeeb40d7a ("content: add vendor specific cfg
> type") had a merge issue. It includes the device normative paragraph for
> Shared memory capability, which was already added right above it by
> commit 855ad7af2bd6 ("shared
On Mon, Oct 04 2021, Halil Pasic wrote:
> On Mon, 04 Oct 2021 09:01:42 +0200
> Cornelia Huck wrote:
>
>> On Sat, Oct 02 2021, "Michael S. Tsirkin" wrote:
>>
>> > On Fri, Oct 01, 2021 at 05:18:46PM +0200, Cornelia Huck wrote:
>> >> I'd say
On Sat, Oct 02 2021, "Michael S. Tsirkin" wrote:
> On Fri, Oct 01, 2021 at 05:18:46PM +0200, Cornelia Huck wrote:
>> I'd say we need a hack here so that we assume little-endian config space
>> if VERSION_1 has been offered; if your patch here works, I assume QE
On Fri, Oct 01 2021, Halil Pasic wrote:
> On Thu, 30 Sep 2021 13:31:04 +0200
> Cornelia Huck wrote:
>
>> On Thu, Sep 30 2021, Halil Pasic wrote:
>>
>> > On Thu, 30 Sep 2021 11:28:23 +0200
>> > Cornelia Huck wrote:
>> >
>> >>
On Thu, Sep 30 2021, Parav Pandit wrote:
> Motivation:
> ==
> Currently when driver initiates a device reset operation, a device may
> not be able finish the reset operation immediately. In such case driver
> waits for an arbitrary amount of time in a hope that device will finish
> the
On Fri, Oct 01 2021, Xuan Zhuo wrote:
> This patch allows the driver to reset a queue individually.
>
> This is very common on general network equipment. By disabling a queue,
> you can quickly reclaim the buffer currently on the queue. If necessary,
> we can reinitialize the queue separately.
>
On Thu, Sep 30 2021, "Michael S. Tsirkin" wrote:
> On Thu, Sep 30, 2021 at 03:20:49AM +0200, Halil Pasic wrote:
>> This patch fixes a regression introduced by commit 82e89ea077b9
>> ("virtio-blk: Add validation for block size in config space") and
>> enables similar checks in verify() on big
On Thu, Sep 30 2021, Halil Pasic wrote:
> On Thu, 30 Sep 2021 11:28:23 +0200
> Cornelia Huck wrote:
>
>> On Thu, Sep 30 2021, Halil Pasic wrote:
>>
>> > This patch fixes a regression introduced by commit 82e89ea077b9
>> > ("virtio-blk: A
On Thu, Sep 30 2021, Jason Wang wrote:
> On Thu, Sep 30, 2021 at 12:33 AM Cornelia Huck wrote:
>>
>> On Wed, Sep 29 2021, Xuan Zhuo wrote:
>>
>> > On Tue, 28 Sep 2021 12:20:46 +0200, Cornelia Huck
>> > wrote:
>> >> On Tue, Sep 28 202
On Thu, Sep 30 2021, Jason Wang wrote:
> On Thu, Sep 30, 2021 at 12:24 AM Cornelia Huck wrote:
>>
>> On Wed, Sep 29 2021, Jason Wang wrote:
>>
>> > On Wed, Sep 29, 2021 at 10:01 AM Xuan Zhuo
>> > wrote:
>> >>
>> >>
On Thu, Sep 30 2021, Halil Pasic wrote:
> This patch fixes a regression introduced by commit 82e89ea077b9
> ("virtio-blk: Add validation for block size in config space") and
> enables similar checks in verify() on big endian platforms.
>
> The problem with checking multi-byte config fields in
On Wed, Sep 29 2021, Xuan Zhuo wrote:
> On Tue, 28 Sep 2021 12:20:46 +0200, Cornelia Huck wrote:
>> On Tue, Sep 28 2021, Xuan Zhuo wrote:
>> > +The device MUST reset the queue when 1 is written to \field{queue_reset},
>> > and
>> > +present a 1 in \field{q
On Wed, Sep 29 2021, Jason Wang wrote:
> On Wed, Sep 29, 2021 at 10:01 AM Xuan Zhuo wrote:
>>
>> On Tue, 28 Sep 2021 12:06:01 +0200, Cornelia Huck wrote:
>> > On Tue, Sep 28 2021, Xuan Zhuo wrote:
>> >
>> > > This patch al
On Wed, Sep 29 2021, "Tian, Kevin" wrote:
>> From: David Gibson
>> Sent: Wednesday, September 29, 2021 10:44 AM
>>
>> > One alternative option is to arrange device nodes in sub-directories based
>> > on the device type. But doing so also adds one trouble to userspace. The
>> > current vfio
On Tue, Sep 28 2021, Xuan Zhuo wrote:
> mmio support virtqueue reset.
>
> MMIO Device Register Layout "QueueReady" to support virtqueue reset.
> The driver uses this to selectively reset the queue.
>
> Signed-off-by: Xuan Zhuo
> ---
> content.tex | 29 -
> 1 file
On Tue, Sep 28 2021, Xuan Zhuo wrote:
> PCI support virtqueue reset.
>
> virtio_pci_common_cfg add "queue_reset" to support virtqueue reset.
> The driver uses this to selectively reset the queue.
>
> Signed-off-by: Xuan Zhuo
> ---
> content.tex | 28
> 1 file
On Tue, Sep 28 2021, Xuan Zhuo wrote:
> This patch allows the driver to reset a queue individually.
>
> This is very common on general network equipment. By disabling a queue,
> you can quickly reclaim the buffer currently on the queue. If necessary,
> we can reinitialize the queue separately.
>
On Tue, Sep 28 2021, Xuan Zhuo wrote:
> On Mon, 27 Sep 2021 16:51:43 +0200, Cornelia Huck wrote:
>> MMIO can probably use a similar mechanism.
>>
>> For CCW, maybe we can add a payload to the existing RESET command if the
>> feature has been negotiated; the queue can
On Tue, Sep 28 2021, Jason Wang wrote:
> On Mon, Sep 27, 2021 at 10:51 PM Cornelia Huck wrote:
>> For CCW, maybe we can add a payload to the existing RESET command if the
>> feature has been negotiated;
>
> I wonder if it's better for a new dedicated command. Co
On Mon, Sep 27 2021, Xuan Zhuo wrote:
> PCI support virtqueue reset.
>
> virtio_pci_common_cfg add "queue_reset" to support virtqueue reset.
> The driver uses this to selectively reset the queue.
>
> Signed-off-by: Xuan Zhuo
> ---
> content.tex | 21 +
> 1 file changed, 21
On Mon, Sep 27 2021, Xuan Zhuo wrote:
> This patch allows the driver to reset a queue individually.
>
> This is very common on general network equipment. By disabling a queue,
> you can quickly reclaim the buffer currently on the queue. If necessary,
> we can reinitialize the queue separately.
>
On Mon, Sep 27 2021, Philippe Mathieu-Daudé wrote:
> On 9/27/21 12:18, Cornelia Huck wrote:
>> On Mon, Sep 06 2021, Philippe Mathieu-Daudé wrote:
>>
>>> Reported-by: Stefano Garzarella
>>> Suggested-by: Stefan Hajnoczi
>>> Signed-off-by: Philippe Mat
On Mon, Sep 06 2021, Philippe Mathieu-Daudé wrote:
> Reported-by: Stefano Garzarella
> Suggested-by: Stefan Hajnoczi
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> include/hw/virtio/virtio.h | 7 +++
> hw/virtio/virtio.c | 1 +
> 2 files changed, 8 insertions(+)
>
> diff --git
On Thu, Sep 23 2021, Junji Wei wrote:
>> On Sep 22, 2021, at 7:28 PM, Cornelia Huck wrote:
>>
>> On Fri, Sep 03 2021, Junji Wei wrote:
>>
>>> Use device ID 42
>>>
>>> Signed-off-by: Junji Wei
>>> ---
>>> conte
On Tue, Sep 21 2021, Pankaj Gupta wrote:
> Posting virtio specification for virtio pmem device. Virtio pmem is a
> paravirtualized device which allows the guest to bypass page cache.
> Virtio pmem kernel driver is merged in Upstream Kernel 5.3. Also, Qemu
> device is merged in Qemu 4.1.
>
>
On Fri, Sep 03 2021, Junji Wei wrote:
> Use device ID 42
>
> Signed-off-by: Junji Wei
> ---
> content.tex | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/content.tex b/content.tex
> index 3aeb4a4..b57c997 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -2878,6 +2878,8 @@
On Wed, Sep 01 2021, Viresh Kumar wrote:
> The I2C protocol allows zero-length requests with no data, like the
> SMBus Quick command, where the command is inferred based on the
> read/write flag itself.
>
> In order to allow such a request, allocate another bit,
> VIRTIO_I2C_FLAGS_M_RD(1), in
On Tue, Sep 21 2021, Halil Pasic wrote:
> On Mon, 20 Sep 2021 12:07:23 +0200
> Cornelia Huck wrote:
>
>> On Mon, Sep 20 2021, Vineeth Vijayan wrote:
>>
>> > On Mon, 2021-09-20 at 00:39 +0200, Halil Pasic wrote:
>> >> On Fri, 17 Sep 2021
On Thu, Sep 09 2021, Jason Gunthorpe wrote:
> Many of the mdev drivers use a simple counter for keeping track of the
> available instances. Move this code to the core code and store the counter
> in the mdev_type. Implement it using correct locking, fixing mdpy.
>
> Drivers provide a
On Thu, Sep 09 2021, Jason Gunthorpe wrote:
> Many of the mdev drivers use a simple counter for keeping track of the
> available instances. Move this code to the core code and store the counter
> in the mdev_type. Implement it using correct locking, fixing mdpy.
>
> Drivers provide a
On Thu, Sep 09 2021, Jason Gunthorpe wrote:
> The subchannel should be left in a quiescent state unless the VFIO device
> FD is opened. When the FD is opened bring the chanel to active and allow
> the VFIO device to operate. When the device FD is closed then quiesce the
> channel.
>
> To make
On Thu, Sep 09 2021, Jason Gunthorpe wrote:
> The subchannel should be left in a quiescent state unless the VFIO device
> FD is opened. When the FD is opened bring the chanel to active and allow
> the VFIO device to operate. When the device FD is closed then quiesce the
> channel.
>
> To make
gt; drivers/s390/cio/vfio_ccw_ops.c | 37 +
> 1 file changed, 15 insertions(+), 22 deletions(-)
Reviewed-by: Cornelia Huck
gt; drivers/s390/cio/vfio_ccw_ops.c | 37 +
> 1 file changed, 15 insertions(+), 22 deletions(-)
Reviewed-by: Cornelia Huck
On Mon, Sep 20 2021, Halil Pasic wrote:
> On Fri, 17 Sep 2021 10:40:20 +0200
> Cornelia Huck wrote:
>
>> On Thu, Sep 16 2021, Halil Pasic wrote:
>>
>> > On Thu, 16 Sep 2021 10:59:15 +0200
>> > Cornelia Huck wrote:
>> >
>> >> >
On Mon, Sep 20 2021, Vineeth Vijayan wrote:
> On Mon, 2021-09-20 at 00:39 +0200, Halil Pasic wrote:
>> On Fri, 17 Sep 2021 10:40:20 +0200
>> Cornelia Huck wrote:
>>
> ...snip...
>> > >
>> > > Thanks, if I find time for it, I will try to un
On Fri, Sep 17 2021, Jason Gunthorpe wrote:
> On Fri, Sep 17, 2021 at 01:59:16PM +0200, Cornelia Huck wrote:
>> >ret = cio_cancel_halt_clear(sch, );
>> > -
>> >if (ret == -EIO) {
>> >pr_err("vfio_ccw: cou
On Fri, Sep 17 2021, Jason Gunthorpe wrote:
> On Fri, Sep 17, 2021 at 01:59:16PM +0200, Cornelia Huck wrote:
>> >ret = cio_cancel_halt_clear(sch, );
>> > -
>> >if (ret == -EIO) {
>> >pr_err("vfio_ccw: cou
onsible for the APEX + HPX integration, but I think it is great.
>
> Best regards,
> Kor
>
>
> On 9/17/21 12:09 AM, Kevin Huck wrote:
>> Kor -
>> Sorry I didn’t reply sooner… I’m glad things are working for you now!
>> The thread naming is a bit odd, be
On Tue, Sep 14 2021, Jason Gunthorpe wrote:
> On Mon, Sep 13, 2021 at 04:31:54PM -0400, Eric Farman wrote:
>> > I rebased it and fixed it up here:
>> >
>> > https://github.com/jgunthorpe/linux/tree/vfio_ccw
>> >
>> > Can you try again?
>>
>> That does address the crash, but then why is it
On Tue, Sep 14 2021, Jason Gunthorpe wrote:
> On Mon, Sep 13, 2021 at 04:31:54PM -0400, Eric Farman wrote:
>> > I rebased it and fixed it up here:
>> >
>> > https://github.com/jgunthorpe/linux/tree/vfio_ccw
>> >
>> > Can you try again?
>>
>> That does address the crash, but then why is it
On Fri, Sep 17 2021, David Gibson wrote:
> Hi all,
>
> At the qemu-in-rust BoF at KVM Forum, I volunteered to look into
> whether Rust supported all the host/build platforms that qemu does,
> which is obviously vital if we want to make Rust a non-optional
> component of the build.
>
> I've added
On Thu, Sep 16 2021, Halil Pasic wrote:
> On Thu, 16 Sep 2021 10:59:15 +0200
> Cornelia Huck wrote:
>
>> > Since commit 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O and
>> > classic notifiers") we were supposed to make sure that
>> > vir
On Wed, Sep 15 2021, Halil Pasic wrote:
> Since commit 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O and
> classic notifiers") we were supposed to make sure that
> virtio_ccw_release_dev() completes before the ccw device, and the
> attached dma pool are torn down, but unfortunately we
On Fri, Sep 10 2021, Christoph Hellwig wrote:
> On Thu, Sep 09, 2021 at 04:38:41PM -0300, Jason Gunthorpe wrote:
>> +
>> +private = kzalloc(sizeof(*private), GFP_KERNEL | GFP_DMA);
>> +if (!private)
>> +return ERR_PTR(-ENOMEM);
>
> Nit: there is no need to add GFP_KERNEL when
On Fri, Sep 10 2021, Christoph Hellwig wrote:
> On Thu, Sep 09, 2021 at 04:38:41PM -0300, Jason Gunthorpe wrote:
>> +
>> +private = kzalloc(sizeof(*private), GFP_KERNEL | GFP_DMA);
>> +if (!private)
>> +return ERR_PTR(-ENOMEM);
>
> Nit: there is no need to add GFP_KERNEL when
of nodes you use (works only for one locality
>>> per node). This should get rid of the "every locality thinks its rank 0"
>>> problem. Please let me know if it works and the two issues were indeed
>>> related.
>>>
>>> Kind regards,
>>&g
> 2 files changed, 42 insertions(+), 42 deletions(-)
Unrelated to your patch, line 143 in removed-features.rst reads
``-vnc ...,tls=...``, ``-vnc ...,x509=...`` & ``-vnc ...,x509verify=...``
and is missing the release it was removed in (presumably 3.1?)
Anyway,
Reviewed-by: Cornelia Huck
> 2 files changed, 42 insertions(+), 42 deletions(-)
Unrelated to your patch, line 143 in removed-features.rst reads
``-vnc ...,tls=...``, ``-vnc ...,x509=...`` & ``-vnc ...,x509verify=...``
and is missing the release it was removed in (presumably 3.1?)
Anyway,
Reviewed-by: Cornelia Huck
701 - 800 of 13946 matches
Mail list logo
