On Tue, 26 Sep 2023 18:41:58 +0200
Halil Pasic wrote:
> > + local_bh_disable();
> > crypto_finalize_akcipher_request(vc_akcipher_req->base.dataq->engine,
> > req, err);
> > + local_bh_enable();
>
> Thanks Gonglei!
>
> I did this a quick s
On Wed, 27 Sep 2023 09:24:09 +
"Gonglei (Arei)" wrote:
> > On a related note, config change callback is also handled incorrectly in
> > this
> > driver, it takes a mutex from interrupt context.
>
> Good catch. Will fix it.
Thanks Gonglei! Sorry I first misunderstood this as a problem
On Wed, 27 Sep 2023 14:12:19 +0200
Cornelia Huck wrote:
> On Wed, Sep 27 2023, Halil Pasic wrote:
>
> > On Wed, 27 Sep 2023 12:08:43 +0200
> > Cornelia Huck wrote:
> >
> >> > On the other hand virtio_airq_handler() calls vring_interrupt() wi
On Wed, 27 Sep 2023 12:08:43 +0200
Cornelia Huck wrote:
> > On the other hand virtio_airq_handler() calls vring_interrupt() with
> > interrupts enabled. (While vring_interrupt() is called in a (read)
> > critical section in virtio_airq_handler() we use read_lock() and
> > not read_lock_irqsave()
On Tue, 26 Sep 2023 13:13:51 -0400
"Michael S. Tsirkin" wrote:
> > On the other hand virtio_airq_handler() calls vring_interrupt() with
> > interrupts enabled. (While vring_interrupt() is called in a (read)
> > critical section in virtio_airq_handler() we use read_lock() and
> > not
[..]
> --- a/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c
> +++ b/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c
> @@ -61,8 +61,9 @@ static void virtio_crypto_akcipher_finalize_req(
> vc_akcipher_req->src_buf = NULL;
> vc_akcipher_req->dst_buf = NULL;
>
On Sun, 24 Sep 2023 11:56:25 +
"Gonglei (Arei)" wrote:
> Hi Halil,
>
> Commit 4058cf08945 introduced a check for detecting crypto completion
> function
> called with enable BH, and indeed the virtio-crypto driver didn't disable BH,
> which needs
> a patch to fix it.
>
> P.S.:
>
Hi Gonglei!
Our CI has found that virtio-crypto does not honor the requirement of
crypto_finalize_request() being called in softirq context which is
asserted in that function via lockdep_assert_in_softirq() since commit
4058cf08945c ("crypto: engine - check if BH is disabled during
completion").
s called via virtio_ccw_int_handler(), a per
> device rwlock is introduced ans used in the synchronization method.
>
> Cc: Thomas Gleixner
> Cc: Peter Zijlstra
> Cc: "Paul E. McKenney"
> Cc: Marc Zyngier
> Cc: Halil Pasic
> Cc: Cornelia Huck
> Cc: Vineeth
On Mon, 23 May 2022 10:53:23 +0200
Halil Pasic wrote:
> On Wed, 18 May 2022 11:59:42 +0800
> Jason Wang wrote:
>
> > Hi All:
>
> Sorry for being slow on this one. I'm pretty much under water. Will try
> to get some regression-testing done till tomorrow end of d
On Wed, 18 May 2022 11:59:42 +0800
Jason Wang wrote:
> Hi All:
Sorry for being slow on this one. I'm pretty much under water. Will try
to get some regression-testing done till tomorrow end of day.
Regards,
Halil
___
Virtualization mailing list
On Thu, 12 May 2022 11:31:08 +0800
Jason Wang wrote:
> > > It looks to me we need to use write_lock_irq()/write_unlock_irq() to
> > > do the synchronization.
> > >
> > > And we probably need to keep the
> > > read_lock_irqsave()/read_lock_irqrestore() logic since I can see the
> > >
On Wed, 11 May 2022 10:22:59 +0800
Jason Wang wrote:
> >CPU0
> >
> > lock(>irq_lock);
> >
> > lock(>irq_lock);
> >
> > *** DEADLOCK ***
>
> It looks to me we need to use write_lock_irq()/write_unlock_irq() to
> do the synchronization.
>
> And we probably need to
On Wed, 11 May 2022 17:27:44 +0800
Jason Wang wrote:
> On Wed, May 11, 2022 at 4:44 PM Cornelia Huck wrote:
> >
> > On Wed, May 11 2022, Jason Wang wrote:
> >
> > > On Tue, May 10, 2022 at 7:32 PM Michael S. Tsirkin
> > > wrote:
> > >>
> > >> On Sat, May 07, 2022 at 03:19:53PM +0800,
t; > On Mon, Apr 25, 2022 at 11:35:41PM -0400, Michael S. Tsirkin wrote:
> >> >> > >
> >> >> > > > On Tue, Apr 26, 2022 at 04:29:11AM +0200, Halil Pasic wrote:
> >> >> > > > > On Mon, 25 Apr 2022 09:59:55 -0400
> >&g
ynchronization
> >> method.
> >>
> >> Cc: Thomas Gleixner
> >> Cc: Peter Zijlstra
> >> Cc: "Paul E. McKenney"
> >> Cc: Marc Zyngier
> >> Cc: Halil Pasic
> >> Cc: Cornelia Huck
> >> Signed-off-by: Jason W
t is called via virtio_ccw_int_handler(), a per
> > >> device spinlock for irq is introduced ans used in the synchronization
> > >> method.
> > >>
> > >> Cc: Thomas Gleixner
> > >> Cc: Peter Zijlstra
> > >> Cc: "
On Tue, 12 Apr 2022 10:24:35 +0800
Jason Wang wrote:
> > Regarding the question "are we safe against notifications before
> > indicators have been registered" I think we really need to think about
> > something like Secure Execution. We don't have, and we are unlikely
> > to have in hardware
On Mon, 11 Apr 2022 16:27:41 +0200
Cornelia Huck wrote:
> On Mon, Apr 11 2022, Jason Wang wrote:
>
> > On Sun, Apr 10, 2022 at 3:51 PM Michael S. Tsirkin wrote:
> >
> >>
> >> On Fri, Apr 08, 2022 at 03:03:07PM +0200, Halil Pasic wrote:
>
On Wed, 06 Apr 2022 15:04:32 +0200
Cornelia Huck wrote:
> On Wed, Apr 06 2022, "Michael S. Tsirkin" wrote:
>
> > On Wed, Apr 06, 2022 at 04:35:37PM +0800, Jason Wang wrote:
> >> This patch implements PCI version of synchronize_vqs().
> >>
> >> Cc: Thomas Gleixner
> >> Cc: Peter Zijlstra
>
ll, so I'm very happy to see us
moving away from that.
>
> Cc: sta...@vger.kernel.org
> Fixes: 404123c2db79 ("virtio: allow drivers to validate features")
> Fixes: 2f9a174f918e ("virtio: write back F_VERSION_1 before validate")
> Cc: "Halil Pasic"
es once unless we are clearing any
> features when validating.
>
> Cc: sta...@vger.kernel.org
> Fixes: 404123c2db79 ("virtio: allow drivers to validate features")
> Fixes: 2f9a174f918e ("virtio: write back F_VERSION_1 before validate")
> Cc: "Halil Pasic"
On Wed, 24 Nov 2021 10:33:28 +0800
Jason Wang wrote:
> > > > Let's see how far we can get. But yes, maybe we were too aggressive in
> > > > breaking things by default, a warning might be a better choice for a
> > > > couple of cycles.
> >
> > Ok, considering we saw the issues with balloons I
est
> buffers (they are all "out" buffers), without writing anything,
> so we must pass 0 as "used length" to comply virtio spec.
>
> Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko")
> Cc: sta...@vger.kernel.org
> Reported-by: Halil Pasic
> Sugge
On Tue, 23 Nov 2021 07:17:05 -0500
"Michael S. Tsirkin" wrote:
> On Mon, Nov 22, 2021 at 02:50:03PM +0100, Halil Pasic wrote:
> > On Mon, 22 Nov 2021 14:25:26 +0800
> > Jason Wang wrote:
> >
> > > On Mon, Nov 22, 2021 at 1:49 PM Halil Pasic wrote:
&
On Mon, 22 Nov 2021 14:25:26 +0800
Jason Wang wrote:
> I think the fixes are:
>
> 1) fixing the vhost vsock
> 2) use suppress_used_validation=true to let vsock driver to validate
> the in buffer length
> 3) probably a new feature so the driver can only enable the validation
> when the feature
On Mon, 22 Nov 2021 12:08:22 +0100
Stefano Garzarella wrote:
> On Mon, Nov 22, 2021 at 08:55:24AM +0100, Stefano Garzarella wrote:
> >On Mon, Nov 22, 2021 at 02:25:26PM +0800, Jason Wang wrote:
> >>On Mon, Nov 22, 2021 at 1:49 PM Halil Pasic wrote:
> >>>
>
On Mon, 22 Nov 2021 14:25:26 +0800
Jason Wang wrote:
> On Mon, Nov 22, 2021 at 1:49 PM Halil Pasic wrote:
> >
> > On Mon, 22 Nov 2021 06:35:18 +0100
> > Halil Pasic wrote:
> >
> > > > I think it should be a common issue, looking at
>
On Mon, 22 Nov 2021 06:35:18 +0100
Halil Pasic wrote:
> > I think it should be a common issue, looking at
> > vhost_vsock_handle_tx_kick(), it did:
> >
> > len += sizeof(pkt->hdr);
> > vhost_add_used(vq, head, len);
> >
> > which looks like a vi
On Mon, 22 Nov 2021 11:51:09 +0800
Jason Wang wrote:
> On Fri, Nov 19, 2021 at 11:10 PM Halil Pasic wrote:
> >
> > On Wed, 27 Oct 2021 10:21:04 +0800
> > Jason Wang wrote:
> >
> > > This patch validate the used buffer length provided by the device
> &g
On Wed, 27 Oct 2021 10:21:04 +0800
Jason Wang wrote:
> This patch validate the used buffer length provided by the device
> before trying to use it. This is done by record the in buffer length
> in a new field in desc_state structure during virtqueue_add(), then we
> can fail the
On Wed, 13 Oct 2021 08:24:53 -0400
"Michael S. Tsirkin" wrote:
> > > OK this looks good! How about a QEMU patch to make it spec compliant on
> > > BE?
> >
> > Who is going to do that? Halil? you? Conny?
>
> Halil said he'll do it... Right, Halil?
I can do it but not right away. Maybe in a
, so at least that's not a regression.
No devices except virtio net and virtio blk seem 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")
Fi
On Fri, 8 Oct 2021 09:05:03 -0400
"Michael S. Tsirkin" wrote:
> On Fri, Oct 08, 2021 at 02:34:22PM +0200, Halil Pasic wrote:
> > The virtio specification virtio-v1.1-cs01 states: "Transitional devices
> > MUST detect Legacy drivers by detecting that VIRTI
atter renders virtio-blk unusable
with DASD backing, because things simply don't work with the default.
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 wh
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 Wed, Oct 06 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 drivers by detecting that VIRTIO_F_VERSION_1 has not
> > been ac
negotiation
is complete. However, we already have regression so let's try to address
it.
Signed-off-by: Halil Pasic
Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block size in config
space")
Fixes: fe36cbe0671e ("virtio_net: clear MTU when out of range")
Reported-by
On Tue, 05 Oct 2021 13:13:31 +0200
Cornelia Huck wrote:
> 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:
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 change the set of features it
> > accepts."
> >
> > in the device initialization section?
>
> Maybe "as long as". However Halil implied
On Tue, 5 Oct 2021 03:53:17 -0400
"Michael S. Tsirkin" wrote:
> > Wouldn't a call from transport code into virtio core
> > be more handy? What I have in mind is stuff like vhost-user and vdpa. My
> > understanding is, that for vhost setups where the config is outside qemu,
> > we probably need a
On Mon, 4 Oct 2021 05:07:13 -0400
"Michael S. Tsirkin" wrote:
> On Mon, Oct 04, 2021 at 04:23:23AM +0200, Halil Pasic wrote:
> > On Sat, 2 Oct 2021 14:13:37 -0400
> > "Michael S. Tsirkin" wrote:
> >
> > > > Anyone else have
On Mon, 4 Oct 2021 09:11:04 -0400
"Michael S. Tsirkin" wrote:
> > >> static inline bool virtio_access_is_big_endian(VirtIODevice *vdev)
> > >> {
> > >> #if defined(LEGACY_VIRTIO_IS_BIENDIAN)
> > >> return virtio_is_big_endian(vdev);
> > >> #elif defined(TARGET_WORDS_BIGENDIAN)
> > >> if
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 we need a hack here so that we assume little-endian config space
> >> if VERSION_1 has been offered; if
isfies "only modern mode", or? For now
I've deliberately omitted the has verify and the is big endian
conditions so we have a better chance to see if something breaks
(i.e. the approach does not work). I can add in those extra conditions
later.
------8<-
On Sat, 2 Oct 2021 14:20:47 -0400
"Michael S. Tsirkin" wrote:
> > >From my perspective the problem is that the version of the device
> > remains in limbo as long as the features have not yet been finalized,
> > which means that the endianness of the config space remains in limbo as
> > well.
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, 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 regression introduced by commit 82e89ea077b9
> > ("virtio-blk: Add validation for block size in config space&qu
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: Add validation for block size in config space") and
> > enables simila
e out whether the device is
transitional by rejecting _F_VERSION_1, then resetting it and proceeding
according tho what we have figured out, hoping that the characteristics
of the device didn't change.
Signed-off-by: Halil Pasic
Fixes: 82e89ea077b9 ("virtio-blk: Add validation for block siz
On Tue, 21 Sep 2021 15:31:03 +0200
Vineeth Vijayan wrote:
> On Tue, 2021-09-21 at 05:25 +0200, 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, 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 10:40:20 +0200
> >> Cornelia Huck wrote:
> >>
> > ...s
On Mon, 20 Sep 2021 12:30:39 +0200
Cornelia Huck wrote:
> On Mon, Sep 20 2021, Halil Pasic wrote:
[..]
>
> Basically, the vcdev is supposed to be around while the ccw device is
> online (with a tail end until references have been given up, of course.)
> It embeds a virtio
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:
> >
> >> > Since commit 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O and
&g
.
> >
> > To accomplish this let us take a reference on the ccw device before we
> > allocate the dma_area and give it up after dma_area was freed.
> >
> > Signed-off-by: Halil Pasic
> > Fixes: 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O
s/vritio/virtio/
(subject)
[..]
On Wed, 15 Sep 2021 23:57:42 +0200
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 be
was freed.
Signed-off-by: Halil Pasic
Fixes: 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O and
classic notifiers")
Reported-by: b...@redhat.com
---
I'm not certain this is the only hot-unplug and teardonw related problem
with virtio-ccw.
Some things that are not perfectly clear
On Tue, 16 Feb 2021 11:39:07 +0100
Cornelia Huck wrote:
> >
> > Reviewed-by: Halil Pasic
>
> Thanks!
>
> I'll do a v2 with a tweaked commit message and cc:stable.
Sounds good!
___
Virtualization mailing list
Vi
ion < 1)
> > + if (vcdev->revision < 2)
> > return vcdev->dma_area->status;
I don't think our faking of the status read (i.e. returning the old one)
is contributing to spec compliance. Especially not if the inability to
READ is not transient.
On Mon, 7 Sep 2020 11:39:05 +0200
Pierre Morel wrote:
> Hi all,
>
> The goal of the series is to give a chance to the architecture
> to validate VIRTIO device features.
Michael, is this going in via your tree?
___
Virtualization mailing list
gured device we fail it (device status field), because
attempting to drive it is a recipe for disaster.
>
> Signed-off-by: Pierre Morel
> Reviewed-by: Cornelia Huck
Reviewed-by: Halil Pasic
___
Virtualization mailing list
Virtualization@li
t set.
>
> Signed-off-by: Pierre Morel
> Reviewed-by: Cornelia Huck
Reviewed-by: Halil Pasic
[..]
>
> +config ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> + bool
> + help
> + This option is selected if the architecture may need to enforce
> + VIRTIO_F
On Thu, 9 Jul 2020 16:51:04 +0200
Pierre Morel wrote:
>
>
> On 2020-07-09 16:47, Halil Pasic wrote:
> > On Thu, 9 Jul 2020 12:51:58 +0200
> > Pierre Morel wrote:
> >
> >>>> +int arch_validate_virtio_features(struct virtio_device *dev)
> &g
On Thu, 9 Jul 2020 12:51:58 +0200
Pierre Morel wrote:
> >> +int arch_validate_virtio_features(struct virtio_device *dev)
> >> +{
> >> + if (!is_prot_virt_guest())
> >> + return 0;
> >> +
> >> + if (!virtio_has_feature(dev, VIRTIO_F_VERSION_1)) {
> >> + dev_warn(>dev, "device
On Thu, 9 Jul 2020 10:39:18 +0200
Pierre Morel wrote:
> An architecture may need to validate the VIRTIO devices features
> based on architecture specifics.
>
> Signed-off-by: Pierre Morel
> Reviewed-by: Cornelia Huck
> Acked-by: Christian Borntraeger
Ack
gt; +"device must provide VIRTIO_F_IOMMU_PLATFORM\n");
>
> "support for limited memory access required for protected
> virtualization"
>
> ?
>
> Mentioning the feature flag is shorter i
On Tue, 7 Jul 2020 12:38:17 +0200
Pierre Morel wrote:
>
>
> On 2020-07-07 11:46, Cornelia Huck wrote:
> > On Tue, 7 Jul 2020 10:44:37 +0200
> > Pierre Morel wrote:
> >
> >> S390, protecting the guest memory against unauthorized host access
> >> needs to enforce VIRTIO I/O device protection
On Fri, 19 Jun 2020 11:20:51 +0200
Cornelia Huck wrote:
> > > + if (arch_needs_virtio_iommu_platform(dev) &&
> > > + !virtio_has_feature(dev, VIRTIO_F_IOMMU_PLATFORM)) {
> > > + dev_warn(>dev,
> > > + "virtio: device must provide
> > >
f preventing calamity, and the details can be changed any time,
thus:
Acked-by: Halil Pasic
Regarding the interaction of architecture specific code with virtio core,
I believe we could have made the interface more generic.
One option is to introduce virtio_arch_finalize_features(), a hook that
cou
On Tue, 16 Jun 2020 12:52:50 +0200
Pierre Morel wrote:
> >> int virtio_finalize_features(struct virtio_device *dev)
> >> {
> >>int ret = dev->config->finalize_features(dev);
> >> @@ -179,6 +184,10 @@ int virtio_finalize_features(struct virtio_device
> >> *dev)
> >>if
On Mon, 15 Jun 2020 14:39:24 +0200
Pierre Morel wrote:
I find the subject (commit short) sub optimal. The 'arch' is already
accepting devices 'without IOMMU feature'. What you are introducing is
the ability to reject.
> An architecture protecting the guest memory against unauthorized host
>
On Mon, 15 Jun 2020 11:01:55 +0800
Jason Wang wrote:
> > hum, in between I found another way which seems to me much better:
> >
> > We already have the force_dma_unencrypted() function available which
> > AFAIU is what we want for encrypted memory protection and is already
> > used by power
On Wed, 10 Jun 2020 15:11:51 +0200
Pierre Morel wrote:
> Protected Virtualisation protects the memory of the guest and
> do not allow a the host to access all of its memory.
>
> Let's refuse a VIRTIO device which does not use IOMMU
> protected access.
>
Should we ever get a virtio-ccw device
Cornelia Huck
Reviewed-by: Halil Pasic
> ---
> drivers/s390/virtio/virtio_ccw.c | 26 --
> 1 file changed, 26 deletions(-)
>
> diff --git a/drivers/s390/virtio/virtio_ccw.c
> b/drivers/s390/virtio/virtio_ccw.c
> index 957889a42d2e..5730572b52cd 1
On Tue, 3 Mar 2020 09:49:21 -0500
"Michael S. Tsirkin" wrote:
> On Tue, Mar 03, 2020 at 03:12:52PM +0100, Halil Pasic wrote:
> > On Thu, 13 Feb 2020 13:37:26 +0100
> > Halil Pasic wrote:
> >
> > > Two patches are handling new edge cases introduced by
On Thu, 13 Feb 2020 13:37:26 +0100
Halil Pasic wrote:
> Two patches are handling new edge cases introduced by doing DMA mappings
> (which can fail) in virtio core.
>
> I stumbled upon this while stress testing I/O for Protected Virtual
> Machines. I deliberately chose a ti
On Fri, 21 Feb 2020 17:36:45 +0100
Christoph Hellwig wrote:
> > By "legacy devices" I assume you mean pre-virtio-1.0 devices, that
> > lack the F_VERSION_1 feature flag. Is that right? Because I don't
> > see how being a legacy device or not relates to use of the DMA API.
>
> No. "legacy"
On Mon, 24 Feb 2020 14:33:14 +1100
David Gibson wrote:
> On Fri, Feb 21, 2020 at 07:07:02PM +0100, Halil Pasic wrote:
> > On Fri, 21 Feb 2020 10:48:15 -0500
> > "Michael S. Tsirkin" wrote:
> >
> > > On Fri, Feb 21, 2020 at 02:06:39PM +0100, Halil Pasic
On Mon, 24 Feb 2020 17:26:20 +0800
Jason Wang wrote:
> That's better.
>
> How about attached?
>
> Thanks
Thanks Jason! It does avoid the translation overhead in vhost.
Tested-by: Halil Pasic
Regarding the code, you fence it in virtio-net.c, but AFAIU this feature
has rele
On Fri, 21 Feb 2020 17:39:38 +0100
Christoph Hellwig wrote:
> On Fri, Feb 21, 2020 at 03:33:40PM +0100, Halil Pasic wrote:
> > > Hell no. This is a detail of the platform DMA direct implementation.
> >
> > I beg to differ. If it was a detail of the DMA direct implementa
On Fri, 21 Feb 2020 10:48:15 -0500
"Michael S. Tsirkin" wrote:
> On Fri, Feb 21, 2020 at 02:06:39PM +0100, Halil Pasic wrote:
> > On Fri, 21 Feb 2020 14:27:27 +1100
> > David Gibson wrote:
> >
> > > On Thu, Feb 20, 2020 at 05:31:35PM +0100, Christoph Hel
On Fri, 21 Feb 2020 10:56:45 -0500
"Michael S. Tsirkin" wrote:
> On Fri, Feb 21, 2020 at 02:12:30PM +0100, Halil Pasic wrote:
> > On Thu, 20 Feb 2020 15:55:14 -0500
> > "Michael S. Tsirkin" wrote:
[..]
> > > To summarize, the necessary conditions f
On Fri, 21 Feb 2020 14:22:26 +0800
Jason Wang wrote:
>
> On 2020/2/21 上午12:06, Halil Pasic wrote:
> > Currently if one intends to run a memory protection enabled VM with
> > virtio devices and linux as the guest OS, one needs to specify the
> > VIRTIO_F_IOMMU_PLATF
On Thu, 20 Feb 2020 17:13:09 +0100
Christoph Hellwig wrote:
> On Thu, Feb 20, 2020 at 05:06:06PM +0100, Halil Pasic wrote:
> > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> > index 867c7ebd3f10..fafc8f924955 100644
> > --- a/drivers/virtio/vi
On Thu, 20 Feb 2020 16:33:35 -0500
"Michael S. Tsirkin" wrote:
> On Thu, Feb 20, 2020 at 05:06:04PM +0100, Halil Pasic wrote:
> > For vhost-net the feature VIRTIO_F_IOMMU_PLATFORM has the following side
> > effect The vhost code assumes it the addresses on the v
On Thu, 20 Feb 2020 16:29:50 -0500
"Michael S. Tsirkin" wrote:
> On Thu, Feb 20, 2020 at 05:06:04PM +0100, Halil Pasic wrote:
> > * This usage is not congruent with standardised semantics of
> > VIRTIO_F_IOMMU_PLATFORM. Guest memory protected is an orthogonal rea
On Fri, 21 Feb 2020 11:41:57 +0800
Jason Wang wrote:
> > I *think* what you are suggesting here is that virtio devices that
> > have !F_IOMMU_PLATFORM should have their dma_ops set up so that the
> > DMA API treats IOVA==PA, which will satisfy what the device expects.
>
>
> Can this work for
On Fri, 21 Feb 2020 13:59:15 +1100
David Gibson wrote:
> On Thu, Feb 20, 2020 at 05:13:09PM +0100, Christoph Hellwig wrote:
> > On Thu, Feb 20, 2020 at 05:06:06PM +0100, Halil Pasic wrote:
> > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> &
On Thu, 20 Feb 2020 15:55:14 -0500
"Michael S. Tsirkin" wrote:
> On Thu, Feb 20, 2020 at 05:06:06PM +0100, Halil Pasic wrote:
> > Currently the advanced guest memory protection technologies (AMD SEV,
> > powerpc secure guest technology and
On Fri, 21 Feb 2020 14:27:27 +1100
David Gibson wrote:
> On Thu, Feb 20, 2020 at 05:31:35PM +0100, Christoph Hellwig wrote:
> > On Thu, Feb 20, 2020 at 05:23:20PM +0100, Christian Borntraeger wrote:
> > > >From a users perspective it makes absolutely perfect sense to use the
> > > bounce buffers
.html#x1-416
(In the spec VIRTIO_F_IOMMU_PLATFORM is called
VIRTIO_F_ACCESS_PLATFORM).
Signed-off-by: Halil Pasic
Tested-by: Ram Pai
Tested-by: Michael Mueller
---
include/linux/dma-direct.h | 9 -
include/linux/mem_encrypt.h | 10 ++
2 files changed, 10 insertions(+), 9
B API".) On s390 this results in severe
performance degradation (c.a. factor 10). BTW with ccw I/O there is
(architecturally) no IOMMU, so the whole address translation makes no
sense in the context of virtio-ccw.
Halil Pasic (2):
mm: move force_dma_unencrypted() to mem_encrypt.h
virtio:
run with protection. This is
especially interesting for s390 as VIRTIO_F_IOMMU_PLATFORM pushes all
the virtio control structures into the first 2G of guest memory:
something we don't necessarily want to do per-default.
Signed-off-by: Halil Pasic
Tested-by: Ram Pai
Tested-by: Michael Mueller
On Wed, 19 Feb 2020 09:46:56 +0800
Ming Lei wrote:
> On Tue, Feb 18, 2020 at 8:35 PM Halil Pasic wrote:
> >
> > On Tue, 18 Feb 2020 10:21:18 +0800
> > Ming Lei wrote:
> >
> > > On Thu, Feb 13, 2020 at 8:38 PM Halil Pasic wrote:
> > > >
&
On Tue, 18 Feb 2020 10:21:18 +0800
Ming Lei wrote:
> On Thu, Feb 13, 2020 at 8:38 PM Halil Pasic wrote:
> >
> > Since nobody else is going to restart our hw_queue for us, the
> > blk_mq_start_stopped_hw_queues() is in virtblk_done() is not sufficient
> > neces
n+0x1aa/0x430
> [ 54.769298] process_one_work+0x156/0x360
> [ 54.769299] worker_thread+0x41/0x3b0
> [ 54.769300] kthread+0xf3/0x130
> [ 54.769302] ? process_one_work+0x360/0x360
> [ 54.769303] ? kthread_bind+0x10/0x10
> [ 54.769305] ret_from_fork+0x35/0x40
>
Let's change the mapping between virtqueue_add errors to BLK_STS
statuses, so that -ENOSPC, which indicates virtqueue full is still
mapped to BLK_STS_DEV_RESOURCE, but -ENOMEM which indicates non-device
specific resource outage is mapped to BLK_STS_RESOURCE.
Signed-off-by: Halil Pasic
---
See
requests. Let us also remove a stale comment.
Signed-off-by: Halil Pasic
Cc: Jens Axboe
Fixes: f7728002c1c7 ("virtio_ring: fix return code on DMA mapping fails")
---
I'm in doubt with regards to the Fixes tag. The thing is, virtio-blk
probably made an assumption on virtqueue_add: the failure
in use I experienced
hangs.
The goal of this series is to fix those hangs.
Halil Pasic (2):
virtio-blk: fix hw_queue stopped on arbitrary error
virtio-blk: improve virtqueue error to BLK_STS
drivers/block/virtio_blk.c | 17 -
1 file changed, 12 insertions(+), 5 deletions
On Tue, 26 Nov 2019 19:45:27 +0100
Christoph Hellwig wrote:
> On Sat, Nov 23, 2019 at 09:39:08AM -0600, Tom Lendacky wrote:
> > Ideally, having a pool of shared pages for DMA, outside of standard
> > SWIOTLB, might be a good thing. On x86, SWIOTLB really seems geared
> > towards devices that
1 - 100 of 189 matches
Mail list logo
