* Re: [RFC] virtio_net: add local_bh_disable() around u64_stats_update_begin
From: Sebastian Andrzej Siewior @ 2018-10-18 9:08 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Michael S. Tsirkin, netdev, virtualization, tglx, David S. Miller
In-Reply-To: <4849237d-38f5-9840-4ab9-4419de31db85@lab.ntt.co.jp>
On 2018-10-18 18:00:05 [+0900], Toshiaki Makita wrote:
> On 2018/10/18 17:47, Sebastian Andrzej Siewior wrote:
> > On 2018-10-17 14:48:02 [+0800], Jason Wang wrote:
> >>
> >> On 2018/10/17 上午9:13, Toshiaki Makita wrote:
> >>> I'm not sure what condition triggered this warning.
> >
> > If the seqlock is acquired once in softirq and then in process context
> > again it is enough evidence for lockdep to trigger this warning.
>
> No. As I said that should not happen because of NAPI guard.
Again: lockdep saw the lock in softirq context once and in process
context once and this is what triggers the warning. It does not matter
if NAPI is enabled or not during the access in process context. If you
want to allow this you need further lockdep annotation…
… but: refill_work() disables NAPI for &vi->rq[1] and refills + updates
stats while NAPI is enabled for &vi->rq[0].
Sebastian
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] virtio_net: add local_bh_disable() around u64_stats_update_begin
From: Sebastian Andrzej Siewior @ 2018-10-18 9:11 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Michael S. Tsirkin, netdev, virtualization, tglx, David S. Miller
In-Reply-To: <0dce3017-9973-af2d-f324-6fe8b5eb5469@lab.ntt.co.jp>
On 2018-10-18 18:06:57 [+0900], Toshiaki Makita wrote:
> NACK. Again, this race should not happen because of NAPI guard.
> We need to investigate why this warning happened.
I tried to explain this. Please see
20181018090812.rry5qgnqxxrjxaii@linutronix.de
Sebastian
^ permalink raw reply
* Re: [RFC] virtio_net: add local_bh_disable() around u64_stats_update_begin
From: Toshiaki Makita @ 2018-10-18 9:19 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Michael S. Tsirkin, netdev, virtualization, tglx, David S. Miller
In-Reply-To: <20181018090812.rry5qgnqxxrjxaii@linutronix.de>
On 2018/10/18 18:08, Sebastian Andrzej Siewior wrote:
> On 2018-10-18 18:00:05 [+0900], Toshiaki Makita wrote:
>> On 2018/10/18 17:47, Sebastian Andrzej Siewior wrote:
>>> On 2018-10-17 14:48:02 [+0800], Jason Wang wrote:
>>>>
>>>> On 2018/10/17 上午9:13, Toshiaki Makita wrote:
>>>>> I'm not sure what condition triggered this warning.
>>>
>>> If the seqlock is acquired once in softirq and then in process context
>>> again it is enough evidence for lockdep to trigger this warning.
>>
>> No. As I said that should not happen because of NAPI guard.
> Again: lockdep saw the lock in softirq context once and in process
> context once and this is what triggers the warning. It does not matter
> if NAPI is enabled or not during the access in process context. If you
> want to allow this you need further lockdep annotation…
>
> … but: refill_work() disables NAPI for &vi->rq[1] and refills + updates
> stats while NAPI is enabled for &vi->rq[0].
Do you mean this is false positive? rq[0] and rq[1] never race with each
other...
--
Toshiaki Makita
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] virtio_net: add local_bh_disable() around u64_stats_update_begin
From: Toshiaki Makita @ 2018-10-18 9:26 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Michael S. Tsirkin, netdev, virtualization, tglx, David S. Miller
In-Reply-To: <20181018091114.jqiedzds2bqezxtb@linutronix.de>
On 2018/10/18 18:11, Sebastian Andrzej Siewior wrote:
> On 2018-10-18 18:06:57 [+0900], Toshiaki Makita wrote:
>> NACK. Again, this race should not happen because of NAPI guard.
>> We need to investigate why this warning happened.
>
> I tried to explain this. Please see
> 20181018090812.rry5qgnqxxrjxaii@linutronix.de
Anyway, if this really happens, then it means try_fill_recv() can be
called concurrently for the same rq, which looks like a far more severe
problem to me. If so, we need to fix it instead.
--
Toshiaki Makita
^ permalink raw reply
* Re: [RFC] virtio_net: add local_bh_disable() around u64_stats_update_begin
From: Sebastian Andrzej Siewior @ 2018-10-18 9:30 UTC (permalink / raw)
To: Toshiaki Makita
Cc: Michael S. Tsirkin, netdev, virtualization, tglx, David S. Miller
In-Reply-To: <55f14915-744b-e11c-bc50-87a872218479@lab.ntt.co.jp>
On 2018-10-18 18:19:21 [+0900], Toshiaki Makita wrote:
> On 2018/10/18 18:08, Sebastian Andrzej Siewior wrote:
> > Again: lockdep saw the lock in softirq context once and in process
> > context once and this is what triggers the warning. It does not matter
> > if NAPI is enabled or not during the access in process context. If you
> > want to allow this you need further lockdep annotation…
> >
> > … but: refill_work() disables NAPI for &vi->rq[1] and refills + updates
> > stats while NAPI is enabled for &vi->rq[0].
>
> Do you mean this is false positive? rq[0] and rq[1] never race with each
> other...
Why? So you can't refill rq[1] and then be interrupted and process NAPI
for rq[0]?
But as I said. If lockdep saw the lock in acquired in softirq (what it
did) _and_ in process context (what it did as well) _once_ then this is
enough evidence for the warning.
If you claim that this can not happen due to NAPI guard [0] then this is
something lockdep does not know about.
[0] which I currently don't understand and therefore sent the patch [1]
as Jason pointed out that in the ->ndo_open case the work is
scheduled and then NAPI is enabled (which means the worker could
disable NAPI and refill but before it finishes, ->ndo_open would
continue and enable NAPI)).
[1] 20181018084753.wefvsypdevbzoadg@linutronix.de
Sebastian
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC] virtio_net: add local_bh_disable() around u64_stats_update_begin
From: Toshiaki Makita @ 2018-10-18 9:53 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Michael S. Tsirkin, netdev, virtualization, tglx, David S. Miller
In-Reply-To: <20181018093035.i56byogaslsnzcnl@linutronix.de>
On 2018/10/18 18:30, Sebastian Andrzej Siewior wrote:
> On 2018-10-18 18:19:21 [+0900], Toshiaki Makita wrote:
>> On 2018/10/18 18:08, Sebastian Andrzej Siewior wrote:
>>> Again: lockdep saw the lock in softirq context once and in process
>>> context once and this is what triggers the warning. It does not matter
>>> if NAPI is enabled or not during the access in process context. If you
>>> want to allow this you need further lockdep annotation…
>>>
>>> … but: refill_work() disables NAPI for &vi->rq[1] and refills + updates
>>> stats while NAPI is enabled for &vi->rq[0].
>>
>> Do you mean this is false positive? rq[0] and rq[1] never race with each
>> other...
>
> Why? So you can't refill rq[1] and then be interrupted and process NAPI
> for rq[0]?
Probably I don't understand what you are trying to say, but rq[0] and
rq[1] are different objects so they can be processed concurrently but
should not affect each other.
>
> But as I said. If lockdep saw the lock in acquired in softirq (what it
> did) _and_ in process context (what it did as well) _once_ then this is
> enough evidence for the warning.
> If you claim that this can not happen due to NAPI guard [0] then this is
> something lockdep does not know about.
The point is that it is not the problem of stats. try_fill_recv() should
not be called for the same rq concurrently in the first place. This
requirement should be satisfied by NAPI guard, so if the NAPI guard
logic is buggy then we need to fix it.
> [0] which I currently don't understand and therefore sent the patch [1]
> as Jason pointed out that in the ->ndo_open case the work is
> scheduled and then NAPI is enabled (which means the worker could
> disable NAPI and refill but before it finishes, ->ndo_open would
> continue and enable NAPI)).
It may be related but I have not investigated it deeply. I'll check if
it can cause this problem later.
> [1] 20181018084753.wefvsypdevbzoadg@linutronix.de
--
Toshiaki Makita
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v3 3/7] PCI: OF: Allow endpoints to bypass the iommu
From: Robin Murphy @ 2018-10-18 10:47 UTC (permalink / raw)
To: Michael S. Tsirkin, Jean-philippe Brucker
Cc: mark.rutland, devicetree, tnowicki, peter.maydell, marc.zyngier,
linux-pci, will.deacon, virtualization, jean-philippe.brucker,
iommu, robh+dt, Bjorn Helgaas, kvmarm
In-Reply-To: <20181017111100-mutt-send-email-mst@kernel.org>
On 17/10/18 16:14, Michael S. Tsirkin wrote:
> On Mon, Oct 15, 2018 at 08:46:41PM +0100, Jean-philippe Brucker wrote:
>> [Replying with my personal address because we're having SMTP issues]
>>
>> On 15/10/2018 11:52, Michael S. Tsirkin wrote:
>>> On Fri, Oct 12, 2018 at 02:41:59PM -0500, Bjorn Helgaas wrote:
>>>> s/iommu/IOMMU/ in subject
>>>>
>>>> On Fri, Oct 12, 2018 at 03:59:13PM +0100, Jean-Philippe Brucker wrote:
>>>>> Using the iommu-map binding, endpoints in a given PCI domain can be
>>>>> managed by different IOMMUs. Some virtual machines may allow a subset of
>>>>> endpoints to bypass the IOMMU. In some case the IOMMU itself is presented
>>>>
>>>> s/case/cases/
>>>>
>>>>> as a PCI endpoint (e.g. AMD IOMMU and virtio-iommu). Currently, when a
>>>>> PCI root complex has an iommu-map property, the driver requires all
>>>>> endpoints to be described by the property. Allow the iommu-map property to
>>>>> have gaps.
>>>>
>>>> I'm not an IOMMU or virtio expert, so it's not obvious to me why it is
>>>> safe to allow devices to bypass the IOMMU. Does this mean a typo in
>>>> iommu-map could inadvertently allow devices to bypass it?
>>>
>>>
>>> Thinking about this comment, I would like to ask: can't the
>>> virtio device indicate the ranges in a portable way?
>>> This would minimize the dependency on dt bindings and ACPI,
>>> enabling support for systems that have neither but do
>>> have virtio e.g. through pci.
>>
>> I thought about adding a PROBE request for this in virtio-iommu, but it
>> wouldn't be usable by a Linux guest because of a bootstrapping problem.
>
> Hmm. At some level it seems wrong to design hardware interfaces
> around how Linux happens to probe things. That can change at any time
> ...
This isn't Linux-specific though. In general it's somewhere between
difficult and impossible to pull in an IOMMU underneath a device after
at device is active, so if any OS wants to use an IOMMU, it's going to
want to know up-front that it's there and which devices it translates so
that it can program said IOMMU appropriately *before* potentially
starting DMA and/or interrupts from the relevant devices. Linux happens
to do things in that order (either by firmware-driven probe-deferral or
just perilous initcall ordering) because it is the only reasonable order
in which to do them. AFAIK the platforms which don't rely on any
firmware description of their IOMMU tend to have a fairly static system
architecture (such that the OS simply makes hard-coded assumptions), so
it's not necessarily entirely clear how they would cope with
virtio-iommu either way.
Robin.
>> Early on, Linux needs a description of device dependencies, to determine
>> in which order to probe them. If the device dependency was described by
>> virtio-iommu itself, the guest could for example initialize a NIC,
>> allocate buffers and start DMA on the physical address space (which aborts
>> if the IOMMU implementation disallows DMA by default), only to find out
>> once the virtio-iommu module is loaded that it needs to cancel all DMA and
>> reconfigure the NIC. With a static description such as iommu-map in DT or
>> ACPI remapping tables, the guest can defer probing of the NIC until the
>> IOMMU is initialized.
>>
>> Thanks,
>> Jean
>
> Could you point me at the code you refer to here?
>
^ permalink raw reply
* Re: [PATCH] virtio_net: add local_bh_disable() around u64_stats_update_begin
From: David Miller @ 2018-10-18 23:23 UTC (permalink / raw)
To: bigeasy; +Cc: mst, netdev, virtualization, tglx
In-Reply-To: <20181018084313.oopu34iwfwgkcwwc@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Thu, 18 Oct 2018 10:43:13 +0200
> on 32bit, lockdep notices that virtnet_open() and refill_work() invoke
> try_fill_recv() from process context while virtnet_receive() invokes the
> same function from BH context. The problem that the seqcounter within
> u64_stats_update_begin() may deadlock if it is interrupted by BH and
> then acquired again.
>
> Introduce u64_stats_update_begin_bh() which disables BH on 32bit
> architectures. Since the BH might interrupt the worker, this new
> function should not limited to SMP like the others which are expected
> to be used in softirq.
>
> With this change we might lose increments but this is okay. The
> important part that the two 32bit parts of the 64bit counter are not
> corrupted.
>
> Fixes: 461f03dc99cf6 ("virtio_net: Add kick stats").
> Suggested-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Trying to get down to the bottom of this:
1) virtnet_receive() runs from softirq but only if NAPI is active and
enabled. It is in this context that it invokes try_fill_recv().
2) refill_work() runs from process context, but disables NAPI (and
thus invocation of virtnet_receive()) before calling
try_fill_recv().
3) virtnet_open() invokes from process context as well, but before the
NAPI instances are enabled, it is same as case #2.
4) virtnet_restore_up() is the same situations as #3.
Therefore I agree that this is a false positive, and simply lockdep
cannot see the NAPI synchronization done by case #2.
I think we shouldn't add unnecessary BH disabling here, and instead
find some way to annotate this for lockdep's sake.
Thank you.
^ permalink raw reply
* Re: [PATCH 7/8] drm/virtio: move virtio_gpu_object_{attach, detach} calls.
From: Dave Airlie @ 2018-10-19 0:33 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: Dave Airlie, LKML, dri-devel, open list:VIRTIO CORE, NET...
In-Reply-To: <20181018070004.mplea3ozamph6uzu@sirius.home.kraxel.org>
On Thu, 18 Oct 2018 at 17:00, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> > > > This to me feels more like a bind/unbind operation rather than a
> > > > populate/unpopulate operation,
> > > >
> > > > bind is " Bind the backend pages into the aperture in the location"
> > > >
> > > > whereas populate is
> > > >
> > > > allocate pages for a ttm.
> > >
> > > I ran into that trap too ;)
> > >
> > > My first attempt was to map this to bind/unbind. But this is not
> > > correct and therefore didn't work very well.
> > >
> > > virtio_gpu_object_attach() will send a scatter list of the pages
> > > allocated for the object to the host (so the host knows where to
> > > copy from/to when processing the transfer_from/to calls). So IMO
> > > it should be done on population not when binding.
> >
> > Well bind on AGP is the same thing, we'd fill the AGP GART table on
> > bind, so that the AGP GPU could access the pages.
>
> > So I'm interested in why using bind/unbind failed if you have some more info?
>
> Need to try again to be sure, but IIRC I saw multiple bind/unbind calls
> for the same object. ttm probably does it to not waste AGB GART address
> space for objects not in use. But for virtio it is pointless overhead.
> But maybe it is just a matter of taking a reference and keeping it for
> the whole lifetime of the object to make the binding permanent ...
Hmm maybe for the bind/unbind, not sure what would cause unbind except
for the object being moved back out of the TT space and into system,
it might be worth confirming what happens here, as I really do feel
bind/unbind is the correct interface to use here.
Dave.
^ permalink raw reply
* Re: [RFC] virtio_net: add local_bh_disable() around u64_stats_update_begin
From: Jason Wang @ 2018-10-19 2:17 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Michael S. Tsirkin, netdev, virtualization, tglx, David S. Miller
In-Reply-To: <20181018084753.wefvsypdevbzoadg@linutronix.de>
On 2018/10/18 下午4:47, Sebastian Andrzej Siewior wrote:
> On 2018-10-17 14:48:02 [+0800], Jason Wang wrote:
>> On 2018/10/17 上午9:13, Toshiaki Makita wrote:
>>> I'm not sure what condition triggered this warning.
> If the seqlock is acquired once in softirq and then in process context
> again it is enough evidence for lockdep to trigger this warning.
>
>>> Toshiaki Makita
>>
>> Or maybe NAPI is enabled unexpectedly somewhere?
>>
>> Btw, the schedule_delayed_work() in virtnet_open() is also suspicious, if
>> the work is executed before virtnet_napi_enable(), there will be a deadloop
>> for napi_disable().
> something like this? It is also likely if it runs OOM on queue 2, it
> will run OOM again on queue 3.
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index fbcfb4d272336..87d6ec4765270 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1263,22 +1263,22 @@ static void refill_work(struct work_struct *work)
> {
> struct virtnet_info *vi =
> container_of(work, struct virtnet_info, refill.work);
> - bool still_empty;
> + int still_empty = 0;
> int i;
>
> for (i = 0; i < vi->curr_queue_pairs; i++) {
> struct receive_queue *rq = &vi->rq[i];
>
> napi_disable(&rq->napi);
> - still_empty = !try_fill_recv(vi, rq, GFP_KERNEL);
> + if (!try_fill_recv(vi, rq, GFP_KERNEL))
> + still_empty++;
> virtnet_napi_enable(rq->vq, &rq->napi);
> -
> - /* In theory, this can happen: if we don't get any buffers in
> - * we will *never* try to fill again.
> - */
> - if (still_empty)
> - schedule_delayed_work(&vi->refill, HZ/2);
> }
> + /* In theory, this can happen: if we don't get any buffers in
> + * we will *never* try to fill again.
> + */
> + if (still_empty)
> + schedule_delayed_work(&vi->refill, HZ/2);
> }
I think this part is not a must or an independent optimization?
Thanks
>
> static int virtnet_receive(struct receive_queue *rq, int budget,
> @@ -1407,12 +1407,13 @@ static int virtnet_open(struct net_device *dev)
> {
> struct virtnet_info *vi = netdev_priv(dev);
> int i, err;
> + int need_refill = 0;
>
> for (i = 0; i < vi->max_queue_pairs; i++) {
> if (i < vi->curr_queue_pairs)
> /* Make sure we have some buffers: if oom use wq. */
> if (!try_fill_recv(vi, &vi->rq[i], GFP_KERNEL))
> - schedule_delayed_work(&vi->refill, 0);
> + need_refill++;
>
> err = xdp_rxq_info_reg(&vi->rq[i].xdp_rxq, dev, i);
> if (err < 0)
> @@ -1428,6 +1429,8 @@ static int virtnet_open(struct net_device *dev)
> virtnet_napi_enable(vi->rq[i].vq, &vi->rq[i].napi);
> virtnet_napi_tx_enable(vi, vi->sq[i].vq, &vi->sq[i].napi);
> }
> + if (need_refill)
> + schedule_delayed_work(&vi->refill, 0);
>
> return 0;
> }
> @@ -2236,6 +2239,7 @@ static int virtnet_restore_up(struct virtio_device *vdev)
> {
> struct virtnet_info *vi = vdev->priv;
> int err, i;
> + int need_refill = 0;
>
> err = init_vqs(vi);
> if (err)
> @@ -2246,13 +2250,15 @@ static int virtnet_restore_up(struct virtio_device *vdev)
> if (netif_running(vi->dev)) {
> for (i = 0; i < vi->curr_queue_pairs; i++)
> if (!try_fill_recv(vi, &vi->rq[i], GFP_KERNEL))
> - schedule_delayed_work(&vi->refill, 0);
> + need_refill++;
>
> for (i = 0; i < vi->max_queue_pairs; i++) {
> virtnet_napi_enable(vi->rq[i].vq, &vi->rq[i].napi);
> virtnet_napi_tx_enable(vi, vi->sq[i].vq,
> &vi->sq[i].napi);
> }
> + if (need_refill)
> + schedule_delayed_work(&vi->refill, 0);
> }
>
> netif_device_attach(vi->dev);
>
>> Thanks
> Sebastian
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] virtio_net: add local_bh_disable() around u64_stats_update_begin
From: Jason Wang @ 2018-10-19 2:19 UTC (permalink / raw)
To: David Miller, bigeasy; +Cc: mst, netdev, virtualization, tglx
In-Reply-To: <20181018.162308.2295937118791060714.davem@davemloft.net>
On 2018/10/19 上午7:23, David Miller wrote:
> From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Date: Thu, 18 Oct 2018 10:43:13 +0200
>
>> on 32bit, lockdep notices that virtnet_open() and refill_work() invoke
>> try_fill_recv() from process context while virtnet_receive() invokes the
>> same function from BH context. The problem that the seqcounter within
>> u64_stats_update_begin() may deadlock if it is interrupted by BH and
>> then acquired again.
>>
>> Introduce u64_stats_update_begin_bh() which disables BH on 32bit
>> architectures. Since the BH might interrupt the worker, this new
>> function should not limited to SMP like the others which are expected
>> to be used in softirq.
>>
>> With this change we might lose increments but this is okay. The
>> important part that the two 32bit parts of the 64bit counter are not
>> corrupted.
>>
>> Fixes: 461f03dc99cf6 ("virtio_net: Add kick stats").
>> Suggested-by: Stephen Hemminger <stephen@networkplumber.org>
>> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Trying to get down to the bottom of this:
>
> 1) virtnet_receive() runs from softirq but only if NAPI is active and
> enabled. It is in this context that it invokes try_fill_recv().
>
> 2) refill_work() runs from process context, but disables NAPI (and
> thus invocation of virtnet_receive()) before calling
> try_fill_recv().
>
> 3) virtnet_open() invokes from process context as well, but before the
> NAPI instances are enabled, it is same as case #2.
>
> 4) virtnet_restore_up() is the same situations as #3.
>
> Therefore I agree that this is a false positive, and simply lockdep
> cannot see the NAPI synchronization done by case #2.
>
> I think we shouldn't add unnecessary BH disabling here, and instead
> find some way to annotate this for lockdep's sake.
>
> Thank you.
>
+1
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH v2 1/6] drm/virtio: track created object state
From: Gerd Hoffmann @ 2018-10-19 6:18 UTC (permalink / raw)
To: dri-devel; +Cc: David Airlie, open list, open list:VIRTIO GPU DRIVER
In-Reply-To: <20181019061847.18958-1-kraxel@redhat.com>
Track whenever the virtio_gpu_object is already created (i.e. host knows
about it) in a new variable. Add checks to virtio_gpu_object_attach()
to do nothing on objects not created yet.
Make virtio_gpu_ttm_bo_destroy() use the new variable too, instead of
expecting hw_res_handle indicating the object state.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 +++
drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_gem.c | 3 ++-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_vq.c | 7 +++++++
6 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h
index d29f0c7c76..5edc22d7a7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -65,6 +65,7 @@ struct virtio_gpu_object {
struct ttm_placement placement;
struct ttm_buffer_object tbo;
struct ttm_bo_kmap_obj kmap;
+ bool created;
};
#define gem_to_virtio_gpu_obj(gobj) \
container_of((gobj), struct virtio_gpu_object, gem_base)
@@ -263,6 +264,7 @@ void virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev,
uint32_t *resid);
void virtio_gpu_resource_id_put(struct virtio_gpu_device *vgdev, uint32_t id);
void virtio_gpu_cmd_create_resource(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object *bo,
uint32_t resource_id,
uint32_t format,
uint32_t width,
@@ -324,6 +326,7 @@ void virtio_gpu_cmd_transfer_to_host_3d(struct virtio_gpu_device *vgdev,
struct virtio_gpu_fence **fence);
void
virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object *bo,
struct virtio_gpu_resource_create_3d *rc_3d,
struct virtio_gpu_fence **fence);
void virtio_gpu_ctrl_ack(struct virtqueue *vq);
diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c b/drivers/gpu/drm/virtio/virtgpu_fb.c
index cea749f4ec..d39f4f3350 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fb.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
@@ -232,7 +232,7 @@ static int virtio_gpufb_create(struct drm_fb_helper *helper,
return PTR_ERR(obj);
virtio_gpu_resource_id_get(vgdev, &resid);
- virtio_gpu_cmd_create_resource(vgdev, resid, format,
+ virtio_gpu_cmd_create_resource(vgdev, obj, resid, format,
mode_cmd.width, mode_cmd.height);
ret = virtio_gpu_object_kmap(obj);
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 82c817f37c..33dbd5aed7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -103,8 +103,9 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
goto fail;
format = virtio_gpu_translate_format(DRM_FORMAT_HOST_XRGB8888);
+ obj = gem_to_virtio_gpu_obj(gobj);
virtio_gpu_resource_id_get(vgdev, &resid);
- virtio_gpu_cmd_create_resource(vgdev, resid, format,
+ virtio_gpu_cmd_create_resource(vgdev, obj, resid, format,
args->width, args->height);
/* attach the object to the resource */
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index f16b875d6a..98bb238e91 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -260,7 +260,7 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
obj = &qobj->gem_base;
if (!vgdev->has_virgl_3d) {
- virtio_gpu_cmd_create_resource(vgdev, res_id, rc->format,
+ virtio_gpu_cmd_create_resource(vgdev, qobj, res_id, rc->format,
rc->width, rc->height);
ret = virtio_gpu_object_attach(vgdev, qobj, res_id, NULL);
@@ -288,7 +288,7 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
rc_3d.nr_samples = cpu_to_le32(rc->nr_samples);
rc_3d.flags = cpu_to_le32(rc->flags);
- virtio_gpu_cmd_resource_create_3d(vgdev, &rc_3d, NULL);
+ virtio_gpu_cmd_resource_create_3d(vgdev, qobj, &rc_3d, NULL);
ret = virtio_gpu_object_attach(vgdev, qobj, res_id, &fence);
if (ret) {
ttm_eu_backoff_reservation(&ticket, &validate_list);
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c
index eca7655374..6611c487d7 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -33,7 +33,7 @@ static void virtio_gpu_ttm_bo_destroy(struct ttm_buffer_object *tbo)
bo = container_of(tbo, struct virtio_gpu_object, tbo);
vgdev = (struct virtio_gpu_device *)bo->gem_base.dev->dev_private;
- if (bo->hw_res_handle)
+ if (bo->created)
virtio_gpu_cmd_unref_resource(vgdev, bo->hw_res_handle);
if (bo->pages)
virtio_gpu_object_free_sg_table(bo);
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 4e2e037aed..3b6904c5b3 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -388,6 +388,7 @@ static int virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
/* create a basic resource */
void virtio_gpu_cmd_create_resource(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object *bo,
uint32_t resource_id,
uint32_t format,
uint32_t width,
@@ -406,6 +407,7 @@ void virtio_gpu_cmd_create_resource(struct virtio_gpu_device *vgdev,
cmd_p->height = cpu_to_le32(height);
virtio_gpu_queue_ctrl_buffer(vgdev, vbuf);
+ bo->created = true;
}
void virtio_gpu_cmd_unref_resource(struct virtio_gpu_device *vgdev,
@@ -772,6 +774,7 @@ void virtio_gpu_cmd_context_detach_resource(struct virtio_gpu_device *vgdev,
void
virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device *vgdev,
+ struct virtio_gpu_object *bo,
struct virtio_gpu_resource_create_3d *rc_3d,
struct virtio_gpu_fence **fence)
{
@@ -786,6 +789,7 @@ virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device *vgdev,
cmd_p->hdr.flags = 0;
virtio_gpu_queue_fenced_ctrl_buffer(vgdev, vbuf, &cmd_p->hdr, fence);
+ bo->created = true;
}
void virtio_gpu_cmd_transfer_to_host_3d(struct virtio_gpu_device *vgdev,
@@ -869,6 +873,9 @@ int virtio_gpu_object_attach(struct virtio_gpu_device *vgdev,
struct scatterlist *sg;
int si, nents;
+ if (!obj->created)
+ return 0;
+
if (!obj->pages) {
int ret;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/6] drm/virtio: use virtio_gpu_object->hw_res_handle in virtio_gpufb_create()
From: Gerd Hoffmann @ 2018-10-19 6:18 UTC (permalink / raw)
To: dri-devel; +Cc: David Airlie, open list, open list:VIRTIO GPU DRIVER
In-Reply-To: <20181019061847.18958-1-kraxel@redhat.com>
Drop pointless resid variable in virtio_gpufb_create(), just use
the hw_res_handle field in virtio_gpu_object directly.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/virtio/virtgpu_fb.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c b/drivers/gpu/drm/virtio/virtgpu_fb.c
index d39f4f3350..800960bdd9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fb.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
@@ -214,7 +214,7 @@ static int virtio_gpufb_create(struct drm_fb_helper *helper,
struct drm_framebuffer *fb;
struct drm_mode_fb_cmd2 mode_cmd = {};
struct virtio_gpu_object *obj;
- uint32_t resid, format, size;
+ uint32_t format, size;
int ret;
mode_cmd.width = sizes->surface_width;
@@ -231,8 +231,8 @@ static int virtio_gpufb_create(struct drm_fb_helper *helper,
if (IS_ERR(obj))
return PTR_ERR(obj);
- virtio_gpu_resource_id_get(vgdev, &resid);
- virtio_gpu_cmd_create_resource(vgdev, obj, resid, format,
+ virtio_gpu_resource_id_get(vgdev, &obj->hw_res_handle);
+ virtio_gpu_cmd_create_resource(vgdev, obj, obj->hw_res_handle, format,
mode_cmd.width, mode_cmd.height);
ret = virtio_gpu_object_kmap(obj);
@@ -242,7 +242,7 @@ static int virtio_gpufb_create(struct drm_fb_helper *helper,
}
/* attach the object to the resource */
- ret = virtio_gpu_object_attach(vgdev, obj, resid, NULL);
+ ret = virtio_gpu_object_attach(vgdev, obj, obj->hw_res_handle, NULL);
if (ret)
goto err_obj_attach;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/6] drm/virtio: use virtio_gpu_object->hw_res_handle in virtio_gpu_mode_dumb_create()
From: Gerd Hoffmann @ 2018-10-19 6:18 UTC (permalink / raw)
To: dri-devel; +Cc: David Airlie, open list, open list:VIRTIO GPU DRIVER
In-Reply-To: <20181019061847.18958-1-kraxel@redhat.com>
Drop pointless resid variable in virtio_gpu_mode_dumb_create(), just use
the hw_res_handle field in virtio_gpu_object directly.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/virtio/virtgpu_gem.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 33dbd5aed7..8d53451ec4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -87,7 +87,6 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
struct virtio_gpu_object *obj;
int ret;
uint32_t pitch;
- uint32_t resid;
uint32_t format;
if (args->bpp != 32)
@@ -104,13 +103,12 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
format = virtio_gpu_translate_format(DRM_FORMAT_HOST_XRGB8888);
obj = gem_to_virtio_gpu_obj(gobj);
- virtio_gpu_resource_id_get(vgdev, &resid);
- virtio_gpu_cmd_create_resource(vgdev, obj, resid, format,
+ virtio_gpu_resource_id_get(vgdev, &obj->hw_res_handle);
+ virtio_gpu_cmd_create_resource(vgdev, obj, obj->hw_res_handle, format,
args->width, args->height);
/* attach the object to the resource */
- obj = gem_to_virtio_gpu_obj(gobj);
- ret = virtio_gpu_object_attach(vgdev, obj, resid, NULL);
+ ret = virtio_gpu_object_attach(vgdev, obj, obj->hw_res_handle, NULL);
if (ret)
goto fail;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 4/6] drm/virtio: use virtio_gpu_object->hw_res_handle in virtio_gpu_resource_create_ioctl()
From: Gerd Hoffmann @ 2018-10-19 6:18 UTC (permalink / raw)
To: dri-devel; +Cc: David Airlie, open list, open list:VIRTIO GPU DRIVER
In-Reply-To: <20181019061847.18958-1-kraxel@redhat.com>
Drop pointless res_id variable in virtio_gpu_resource_create_ioctl(),
just use the hw_res_handle field in virtio_gpu_object directly.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 24 ++++++++----------------
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 98bb238e91..ebb0920411 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -217,7 +217,6 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
struct virtio_gpu_device *vgdev = dev->dev_private;
struct drm_virtgpu_resource_create *rc = data;
int ret;
- uint32_t res_id;
struct virtio_gpu_object *qobj;
struct drm_gem_object *obj;
uint32_t handle = 0;
@@ -244,8 +243,6 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
INIT_LIST_HEAD(&validate_list);
memset(&mainbuf, 0, sizeof(struct ttm_validate_buffer));
- virtio_gpu_resource_id_get(vgdev, &res_id);
-
size = rc->size;
/* allocate a single page size object */
@@ -253,17 +250,16 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
size = PAGE_SIZE;
qobj = virtio_gpu_alloc_object(dev, size, false, false);
- if (IS_ERR(qobj)) {
- ret = PTR_ERR(qobj);
- goto fail_id;
- }
+ if (IS_ERR(qobj))
+ return PTR_ERR(qobj);
obj = &qobj->gem_base;
+ virtio_gpu_resource_id_get(vgdev, &qobj->hw_res_handle);
if (!vgdev->has_virgl_3d) {
- virtio_gpu_cmd_create_resource(vgdev, qobj, res_id, rc->format,
+ virtio_gpu_cmd_create_resource(vgdev, qobj, qobj->hw_res_handle, rc->format,
rc->width, rc->height);
- ret = virtio_gpu_object_attach(vgdev, qobj, res_id, NULL);
+ ret = virtio_gpu_object_attach(vgdev, qobj, qobj->hw_res_handle, NULL);
} else {
/* use a gem reference since unref list undoes them */
drm_gem_object_get(&qobj->gem_base);
@@ -276,7 +272,7 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
goto fail_unref;
}
- rc_3d.resource_id = cpu_to_le32(res_id);
+ rc_3d.resource_id = cpu_to_le32(qobj->hw_res_handle);
rc_3d.target = cpu_to_le32(rc->target);
rc_3d.format = cpu_to_le32(rc->format);
rc_3d.bind = cpu_to_le32(rc->bind);
@@ -289,7 +285,7 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
rc_3d.flags = cpu_to_le32(rc->flags);
virtio_gpu_cmd_resource_create_3d(vgdev, qobj, &rc_3d, NULL);
- ret = virtio_gpu_object_attach(vgdev, qobj, res_id, &fence);
+ ret = virtio_gpu_object_attach(vgdev, qobj, qobj->hw_res_handle, &fence);
if (ret) {
ttm_eu_backoff_reservation(&ticket, &validate_list);
goto fail_unref;
@@ -297,8 +293,6 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
ttm_eu_fence_buffer_objects(&ticket, &validate_list, &fence->f);
}
- qobj->hw_res_handle = res_id;
-
ret = drm_gem_handle_create(file_priv, obj, &handle);
if (ret) {
@@ -311,7 +305,7 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
}
drm_gem_object_put_unlocked(obj);
- rc->res_handle = res_id; /* similiar to a VM address */
+ rc->res_handle = qobj->hw_res_handle; /* similiar to a VM address */
rc->bo_handle = handle;
if (vgdev->has_virgl_3d) {
@@ -326,8 +320,6 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
}
//fail_obj:
// drm_gem_object_handle_unreference_unlocked(obj);
-fail_id:
- virtio_gpu_resource_id_put(vgdev, res_id);
return ret;
}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 5/6] drm/virtio: drop resource_id argument.
From: Gerd Hoffmann @ 2018-10-19 6:18 UTC (permalink / raw)
To: dri-devel; +Cc: David Airlie, open list, open list:VIRTIO GPU DRIVER
In-Reply-To: <20181019061847.18958-1-kraxel@redhat.com>
We pass the obj anyway, so obj->hw_res_handle can be used instead
in virtio_gpu_object_attach() and virtio_gpu_cmd_create_resource().
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 --
drivers/gpu/drm/virtio/virtgpu_fb.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_gem.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 6 +++---
drivers/gpu/drm/virtio/virtgpu_ttm.c | 3 +--
drivers/gpu/drm/virtio/virtgpu_vq.c | 7 ++-----
6 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 5edc22d7a7..c6b0a938ba 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -265,7 +265,6 @@ void virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev,
void virtio_gpu_resource_id_put(struct virtio_gpu_device *vgdev, uint32_t id);
void virtio_gpu_cmd_create_resource(struct virtio_gpu_device *vgdev,
struct virtio_gpu_object *bo,
- uint32_t resource_id,
uint32_t format,
uint32_t width,
uint32_t height);
@@ -287,7 +286,6 @@ void virtio_gpu_cmd_set_scanout(struct virtio_gpu_device *vgdev,
uint32_t x, uint32_t y);
int virtio_gpu_object_attach(struct virtio_gpu_device *vgdev,
struct virtio_gpu_object *obj,
- uint32_t resource_id,
struct virtio_gpu_fence **fence);
void virtio_gpu_object_detach(struct virtio_gpu_device *vgdev,
struct virtio_gpu_object *obj);
diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c b/drivers/gpu/drm/virtio/virtgpu_fb.c
index 800960bdd9..c22a8246b6 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fb.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
@@ -232,7 +232,7 @@ static int virtio_gpufb_create(struct drm_fb_helper *helper,
return PTR_ERR(obj);
virtio_gpu_resource_id_get(vgdev, &obj->hw_res_handle);
- virtio_gpu_cmd_create_resource(vgdev, obj, obj->hw_res_handle, format,
+ virtio_gpu_cmd_create_resource(vgdev, obj, format,
mode_cmd.width, mode_cmd.height);
ret = virtio_gpu_object_kmap(obj);
@@ -242,7 +242,7 @@ static int virtio_gpufb_create(struct drm_fb_helper *helper,
}
/* attach the object to the resource */
- ret = virtio_gpu_object_attach(vgdev, obj, obj->hw_res_handle, NULL);
+ ret = virtio_gpu_object_attach(vgdev, obj, NULL);
if (ret)
goto err_obj_attach;
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 8d53451ec4..665d18a49d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -104,11 +104,11 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
format = virtio_gpu_translate_format(DRM_FORMAT_HOST_XRGB8888);
obj = gem_to_virtio_gpu_obj(gobj);
virtio_gpu_resource_id_get(vgdev, &obj->hw_res_handle);
- virtio_gpu_cmd_create_resource(vgdev, obj, obj->hw_res_handle, format,
+ virtio_gpu_cmd_create_resource(vgdev, obj, format,
args->width, args->height);
/* attach the object to the resource */
- ret = virtio_gpu_object_attach(vgdev, obj, obj->hw_res_handle, NULL);
+ ret = virtio_gpu_object_attach(vgdev, obj, NULL);
if (ret)
goto fail;
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index ebb0920411..6179d93167 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -256,10 +256,10 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
virtio_gpu_resource_id_get(vgdev, &qobj->hw_res_handle);
if (!vgdev->has_virgl_3d) {
- virtio_gpu_cmd_create_resource(vgdev, qobj, qobj->hw_res_handle, rc->format,
+ virtio_gpu_cmd_create_resource(vgdev, qobj, rc->format,
rc->width, rc->height);
- ret = virtio_gpu_object_attach(vgdev, qobj, qobj->hw_res_handle, NULL);
+ ret = virtio_gpu_object_attach(vgdev, qobj, NULL);
} else {
/* use a gem reference since unref list undoes them */
drm_gem_object_get(&qobj->gem_base);
@@ -285,7 +285,7 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
rc_3d.flags = cpu_to_le32(rc->flags);
virtio_gpu_cmd_resource_create_3d(vgdev, qobj, &rc_3d, NULL);
- ret = virtio_gpu_object_attach(vgdev, qobj, qobj->hw_res_handle, &fence);
+ ret = virtio_gpu_object_attach(vgdev, qobj, &fence);
if (ret) {
ttm_eu_backoff_reservation(&ticket, &validate_list);
goto fail_unref;
diff --git a/drivers/gpu/drm/virtio/virtgpu_ttm.c b/drivers/gpu/drm/virtio/virtgpu_ttm.c
index e3152d45c5..cd63dffa6d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ttm.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ttm.c
@@ -347,8 +347,7 @@ static void virtio_gpu_bo_move_notify(struct ttm_buffer_object *tbo,
} else if (new_mem->placement & TTM_PL_FLAG_TT) {
if (bo->hw_res_handle) {
- virtio_gpu_object_attach(vgdev, bo, bo->hw_res_handle,
- NULL);
+ virtio_gpu_object_attach(vgdev, bo, NULL);
}
}
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 3b6904c5b3..ea3d13793d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -389,7 +389,6 @@ static int virtio_gpu_queue_cursor(struct virtio_gpu_device *vgdev,
/* create a basic resource */
void virtio_gpu_cmd_create_resource(struct virtio_gpu_device *vgdev,
struct virtio_gpu_object *bo,
- uint32_t resource_id,
uint32_t format,
uint32_t width,
uint32_t height)
@@ -401,7 +400,7 @@ void virtio_gpu_cmd_create_resource(struct virtio_gpu_device *vgdev,
memset(cmd_p, 0, sizeof(*cmd_p));
cmd_p->hdr.type = cpu_to_le32(VIRTIO_GPU_CMD_RESOURCE_CREATE_2D);
- cmd_p->resource_id = cpu_to_le32(resource_id);
+ cmd_p->resource_id = cpu_to_le32(bo->hw_res_handle);
cmd_p->format = cpu_to_le32(format);
cmd_p->width = cpu_to_le32(width);
cmd_p->height = cpu_to_le32(height);
@@ -865,7 +864,6 @@ void virtio_gpu_cmd_submit(struct virtio_gpu_device *vgdev,
int virtio_gpu_object_attach(struct virtio_gpu_device *vgdev,
struct virtio_gpu_object *obj,
- uint32_t resource_id,
struct virtio_gpu_fence **fence)
{
bool use_dma_api = !virtio_has_iommu_quirk(vgdev->vdev);
@@ -909,10 +907,9 @@ int virtio_gpu_object_attach(struct virtio_gpu_device *vgdev,
ents[si].padding = 0;
}
- virtio_gpu_cmd_resource_attach_backing(vgdev, resource_id,
+ virtio_gpu_cmd_resource_attach_backing(vgdev, obj->hw_res_handle,
ents, nents,
fence);
- obj->hw_res_handle = resource_id;
return 0;
}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 6/6] drm/virtio: fix resource id handling
From: Gerd Hoffmann @ 2018-10-19 6:18 UTC (permalink / raw)
To: dri-devel; +Cc: David Airlie, open list, open list:VIRTIO GPU DRIVER
In-Reply-To: <20181019061847.18958-1-kraxel@redhat.com>
Move virtio_gpu_resource_id_{get,put} to virtgpu_object.c and make them
static. Allocate and free the id on creation and destroy, drop all
other calls. That way objects have a valid handle for the whole
lifetime of the object.
Also fixes ids leaking. Worst offender are dumb buffers, and I think
some error paths too.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ---
drivers/gpu/drm/virtio/virtgpu_fb.c | 1 -
drivers/gpu/drm/virtio/virtgpu_gem.c | 1 -
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 1 -
drivers/gpu/drm/virtio/virtgpu_object.c | 23 +++++++++++++++++++++++
drivers/gpu/drm/virtio/virtgpu_vq.c | 20 --------------------
6 files changed, 23 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h
index c6b0a938ba..78ad8f58ed 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -260,9 +260,6 @@ int virtio_gpu_surface_dirty(struct virtio_gpu_framebuffer *qfb,
/* virtio vg */
int virtio_gpu_alloc_vbufs(struct virtio_gpu_device *vgdev);
void virtio_gpu_free_vbufs(struct virtio_gpu_device *vgdev);
-void virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev,
- uint32_t *resid);
-void virtio_gpu_resource_id_put(struct virtio_gpu_device *vgdev, uint32_t id);
void virtio_gpu_cmd_create_resource(struct virtio_gpu_device *vgdev,
struct virtio_gpu_object *bo,
uint32_t format,
diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c b/drivers/gpu/drm/virtio/virtgpu_fb.c
index c22a8246b6..fb1cc8b2f1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_fb.c
+++ b/drivers/gpu/drm/virtio/virtgpu_fb.c
@@ -231,7 +231,6 @@ static int virtio_gpufb_create(struct drm_fb_helper *helper,
if (IS_ERR(obj))
return PTR_ERR(obj);
- virtio_gpu_resource_id_get(vgdev, &obj->hw_res_handle);
virtio_gpu_cmd_create_resource(vgdev, obj, format,
mode_cmd.width, mode_cmd.height);
diff --git a/drivers/gpu/drm/virtio/virtgpu_gem.c b/drivers/gpu/drm/virtio/virtgpu_gem.c
index 665d18a49d..f065863939 100644
--- a/drivers/gpu/drm/virtio/virtgpu_gem.c
+++ b/drivers/gpu/drm/virtio/virtgpu_gem.c
@@ -103,7 +103,6 @@ int virtio_gpu_mode_dumb_create(struct drm_file *file_priv,
format = virtio_gpu_translate_format(DRM_FORMAT_HOST_XRGB8888);
obj = gem_to_virtio_gpu_obj(gobj);
- virtio_gpu_resource_id_get(vgdev, &obj->hw_res_handle);
virtio_gpu_cmd_create_resource(vgdev, obj, format,
args->width, args->height);
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
index 6179d93167..bc5afa4f90 100644
--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
@@ -253,7 +253,6 @@ static int virtio_gpu_resource_create_ioctl(struct drm_device *dev, void *data,
if (IS_ERR(qobj))
return PTR_ERR(qobj);
obj = &qobj->gem_base;
- virtio_gpu_resource_id_get(vgdev, &qobj->hw_res_handle);
if (!vgdev->has_virgl_3d) {
virtio_gpu_cmd_create_resource(vgdev, qobj, rc->format,
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c
index 6611c487d7..8bd1ebe13b 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -25,6 +25,26 @@
#include "virtgpu_drv.h"
+static void virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev,
+ uint32_t *resid)
+{
+ int handle;
+
+ idr_preload(GFP_KERNEL);
+ spin_lock(&vgdev->resource_idr_lock);
+ handle = idr_alloc(&vgdev->resource_idr, NULL, 1, 0, GFP_NOWAIT);
+ spin_unlock(&vgdev->resource_idr_lock);
+ idr_preload_end();
+ *resid = handle;
+}
+
+static void virtio_gpu_resource_id_put(struct virtio_gpu_device *vgdev, uint32_t id)
+{
+ spin_lock(&vgdev->resource_idr_lock);
+ idr_remove(&vgdev->resource_idr, id);
+ spin_unlock(&vgdev->resource_idr_lock);
+}
+
static void virtio_gpu_ttm_bo_destroy(struct ttm_buffer_object *tbo)
{
struct virtio_gpu_object *bo;
@@ -40,6 +60,7 @@ static void virtio_gpu_ttm_bo_destroy(struct ttm_buffer_object *tbo)
if (bo->vmap)
virtio_gpu_object_kunmap(bo);
drm_gem_object_release(&bo->gem_base);
+ virtio_gpu_resource_id_put(vgdev, bo->hw_res_handle);
kfree(bo);
}
@@ -81,9 +102,11 @@ int virtio_gpu_object_create(struct virtio_gpu_device *vgdev,
bo = kzalloc(sizeof(struct virtio_gpu_object), GFP_KERNEL);
if (bo == NULL)
return -ENOMEM;
+ virtio_gpu_resource_id_get(vgdev, &bo->hw_res_handle);
size = roundup(size, PAGE_SIZE);
ret = drm_gem_object_init(vgdev->ddev, &bo->gem_base, size);
if (ret != 0) {
+ virtio_gpu_resource_id_put(vgdev, bo->hw_res_handle);
kfree(bo);
return ret;
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
index ea3d13793d..d2861da2bb 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -38,26 +38,6 @@
+ MAX_INLINE_CMD_SIZE \
+ MAX_INLINE_RESP_SIZE)
-void virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev,
- uint32_t *resid)
-{
- int handle;
-
- idr_preload(GFP_KERNEL);
- spin_lock(&vgdev->resource_idr_lock);
- handle = idr_alloc(&vgdev->resource_idr, NULL, 1, 0, GFP_NOWAIT);
- spin_unlock(&vgdev->resource_idr_lock);
- idr_preload_end();
- *resid = handle;
-}
-
-void virtio_gpu_resource_id_put(struct virtio_gpu_device *vgdev, uint32_t id)
-{
- spin_lock(&vgdev->resource_idr_lock);
- idr_remove(&vgdev->resource_idr, id);
- spin_unlock(&vgdev->resource_idr_lock);
-}
-
void virtio_gpu_ctrl_ack(struct virtqueue *vq)
{
struct drm_device *dev = vq->vdev->priv;
--
2.9.3
^ permalink raw reply related
* Call for Papers - WorldCIST'19 - La Toja Island, Spain
From: Maria Lemos @ 2018-10-19 16:27 UTC (permalink / raw)
To: virtualization
[-- Attachment #1.1: Type: text/plain, Size: 9253 bytes --]
*** Best papers published in JCR/SCI/SSCI journals
------------------------------ -----------------------------
WorldCIST'19 - 7th World Conference on Information Systems and Technologies
16 - 19 April 2019 | La Toja Island, Spain
http://www.worldcist.org/ <http://www.worldcist.org/>
------------------------------ ------------------------------ ------------------------------ ------
Scope
The WorldCist'19 - 7th World Conference on Information Systems and Technologies, to be held at La Toja Island, Galicia, Spain, 16 - 19 April 2019, is a global forum for researchers and practitioners to present and discuss the most recent innovations, trends, results, experiences and concerns in the several perspectives of Information Systems and Technologies.
We are pleased to invite you to submit your papers to WorldCist'18. All submissions will be reviewed on the basis of relevance, originality, importance and clarity.
Themes
Submitted papers should be related with one or more of the main themes proposed for the Conference:
A) Information and Knowledge Management (IKM);
B) Organizational Models and Information Systems (OMIS);
C) Software and Systems Modeling (SSM);
D) Software Systems, Architectures, Applications and Tools (SSAAT);
E) Multimedia Systems and Applications (MSA);
F) Computer Networks, Mobility and Pervasive Systems (CNMPS);
G) Intelligent and Decision Support Systems (IDSS);
H) Big Data Analytics and Applications (BDAA);
I) Human-Computer Interaction (HCI);
J) Ethics, Computers and Security (ECS)
K) Health Informatics (HIS);
L) Information Technologies in Education (ITE);
M) Information Technologies in Radiocommunications (ITR);
N) Technologies for Biomedical Applications (TBA)
Types of Submissions and Decisions
Four types of papers can be submitted:
Full paper: Finished or consolidated R&D works, to be included in one of the Conference themes. These papers are assigned a 10-page limit.
Short paper: Ongoing works with relevant preliminary results, open to discussion. These papers are assigned a 7-page limit.
Poster paper: Initial work with relevant ideas, open to discussion. These papers are assigned to a 4-page limit.
Company paper: Companies' papers that show practical experience, R & D, tools, etc., focused on some topics of the conference. These papers are assigned to a 4-page limit.
Submitted papers must comply with the format of Advances in Intelligent Systems and Computing Series (see Instructions for Authors at Springer Website <https://www.springer.com/us/authors-editors/conference-proceedings/conference-proceedings-guidelines> or download a Word Template <ftp://ftp.springernature.com/cs-proceeding/llncs/word/splnproc1703.zip>or Latex Package <ftp://ftp.springernature.com/cs-proceeding/svproc/templates/ProcSci_TeX.zip>) be written in English, must not have been published before, not be under review for any other conference or publication and not include any information leading to the authors’ identification. Therefore, the authors’ names, affiliations and bibliographic references should not be included in the version for evaluation by the Program Committee. This information should only be included in the camera-ready version, saved in Word or Latex format and also in PDF format. These files must be accompanied by the Consent to Publish form <http://worldcist.org/copyright.pdf> filled out, in a ZIP file, and uploaded at the conference management system.
All papers will be subjected to a “double-blind review” by at least two members of the Program Committee.
Based on Program Committee evaluation, a paper can be rejected or accepted by the Conference Chairs. In the later case, it can be accepted as the type originally submitted or as another type. Thus, full papers can be accepted as short papers or poster papers only. Similarly, short papers can be accepted as poster papers only. In these cases, the authors will be allowed to maintain the original number of pages in the camera-ready version.
The authors of accepted poster papers must also build and print a poster to be exhibited during the Conference. This poster must follow an A1 or A2 vertical format. The Conference can includes Work Sessions where these posters are presented and orally discussed, with a 5 minute limit per poster.
The authors of accepted full papers will have 15 minutes to present their work in a Conference Work Session; approximately 5 minutes of discussion will follow each presentation. The authors of accepted short papers and company papers will have 11 minutes to present their work in a Conference Work Session; approximately 4 minutes of discussion will follow each presentation.
Publication and Indexing
To ensure that a full paper, short paper, poster paper or company paper is published, at least one of the authors must be fully registered by the 13th of January 2019, and the paper must comply with the suggested layout and page-limit. Additionally, all recommended changes must be addressed by the authors before they submit the camera-ready version.
No more than one paper per registration will be published. An extra fee must be paid for publication of additional papers, with a maximum of one additional paper per registration. One registration permits only the participation of one author in the conference.
Full and short papers will be published in Proceedings by Springer, in Advances in Intelligent Systems and Computing <http://www.springer.com/series/11156> series. Poster and company papers will not be published, just presented in the conference.
Published full and short papers will be submitted for indexation by ISI, EI-Compendex, SCOPUS, DBLP and Google Scholar, among others, and will be available in the SpringerLink Digital Library.
The authors of the best selected papers will be invited to extend them for publication in international journals indexed by ISI/SCI, SCOPUS and DBLP, among others, such as:
International Journal of Neural Systems <https://www.worldscientific.com/worldscinet/ijns> (IF: 4.58 / Q1)
Integrated Computer-Aided Engineering <http://www.iospress.nl/journal/integrated-computer-aided-engineering/> (IF: 3.667 / Q1)
Telecommunications Policy <https://www.journals.elsevier.com/telecommunications-policy> (IF: 2.087 / Q1)
Group Decision and Negotiation <https://www.springer.com/business+%26+management/operations+research/journal/10726> (IF: 1.869 / Q1)
Computers in Industry <https://www.journals.elsevier.com/computers-in-industry> (IF: 2.850 / Q2)
Journal of Medical Systems <http://www.springer.com/public+health/journal/10916> (IF: 2.098 / Q2)
Computer Languages, Systems & Structures <https://www.journals.elsevier.com/computer-languages-systems-and-structures/> (IF: 1.840 / Q2)
Cluster Computing <https://www.springer.com/computer/communication+networks/journal/10586> (IF: 1.601 / Q2)
Expert Systems - Journal of Knowledge Engineering <http://onlinelibrary.wiley.com/journal/10.1111/(ISSN)1468-0394> (IF: 1.43 / Q2)
Informatica - An International Journal <https://www.mii.lt/informatica/> (IF: 1.386 / Q2)
Journal of Intelligent & Fuzzy Systems <https://www.iospress.nl/journal/journal-of-intelligent-fuzzy-systems/> (IF: 1.426 / Q3)
Enterprise Information Systems <https://www.tandfonline.com/toc/teis20/current> (IF: 1.683 / Q3)
Data Technologies and Applications <http://www.emeraldgrouppublishing.com/products/journals/journals.htm?id=dta> (IF: 1.170 / Q3)
Innovations in Education and Teaching International <https://www.tandfonline.com/toc/riie20/current> (IF: 1.106 / Q3)
Intelligent Data Analysis <http://www.iospress.nl/journal/intelligent-data-analysis> (IF: 0.691 / Q4)
Computational and Mathematical Organization Theory <http://www.springer.com/business+%26+management/journal/10588> (IF: 0.641 / Q4)
AI Communications <https://www.iospress.nl/journal/ai-communications/> (IF: 0.461 / Q4)
Journal of Web Engineering <http://www.riverpublishers.com/journal.php?j=JWE/17/4> (IF: 0.311 / Q4)
Journal of Database Management <https://www.igi-global.com/journal/journal-database-management/1072> (IF: 0.231 / Q4)
Journal of Hospitality and Tourism Technology <http://www.emeraldgrouppublishing.com/products/journals/journals.htm?id=jhtt> (ISI - Emerging Sources Citation Index)
Computer Methods in Biomechanics and Biomedical Engineering - Imaging & Visualization <http://www.tandfonline.com/action/journalInformation?show=aimsScope&journalCode=tciv20#.V4KqBzUmMQs> (ISI - Emerging Sources Citation Index)
Journal of Information Systems Engineering & Management <http://www.lectitojournals.com/journal-for-information-systems-engineering-management>
Important Dates
Paper Submission: November 18, 2018
Notification of Acceptance: December 30, 2018
Payment of Registration, to ensure the inclusion of an accepted paper in the conference proceedings: January 13, 2019.
Camera-ready Submission: January 13, 2019
Website of WorldCIST'19: http://www.worldcist.org/ <http://www.worldcist.org/>
---
This email has been checked for viruses by AVG.
https://www.avg.com
[-- Attachment #1.2: Type: text/html, Size: 20385 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v3 3/7] PCI: OF: Allow endpoints to bypass the iommu
From: Jean-Philippe Brucker @ 2018-10-22 11:27 UTC (permalink / raw)
To: Michael S. Tsirkin, Jean-philippe Brucker
Cc: mark.rutland, devicetree, tnowicki, peter.maydell, marc.zyngier,
linux-pci, will.deacon, virtualization, iommu, robh+dt,
Bjorn Helgaas, robin.murphy, kvmarm
In-Reply-To: <20181017111100-mutt-send-email-mst@kernel.org>
On 17/10/2018 16:14, Michael S. Tsirkin wrote:
>>> Thinking about this comment, I would like to ask: can't the
>>> virtio device indicate the ranges in a portable way?
>>> This would minimize the dependency on dt bindings and ACPI,
>>> enabling support for systems that have neither but do
>>> have virtio e.g. through pci.
>>
>> I thought about adding a PROBE request for this in virtio-iommu, but it
>> wouldn't be usable by a Linux guest because of a bootstrapping problem.
>
> Hmm. At some level it seems wrong to design hardware interfaces
> around how Linux happens to probe things. That can change at any time
> ...
I suspect that most other OS will also solve this class of problem using
a standard such as DT or ACPI, because they also provide dependency for
clock, interrupts, power management, etc. We can add a self-contained
PROBE method if someone makes a case for it, but it's unlikely to get
used at all, and nearly impossible to implement in Linux. The host would
still need a method to tell the guest which device to probe first, for
example with kernel parameters.
>> Early on, Linux needs a description of device dependencies, to determine
>> in which order to probe them. If the device dependency was described by
>> virtio-iommu itself, the guest could for example initialize a NIC,
>> allocate buffers and start DMA on the physical address space (which aborts
>> if the IOMMU implementation disallows DMA by default), only to find out
>> once the virtio-iommu module is loaded that it needs to cancel all DMA and
>> reconfigure the NIC. With a static description such as iommu-map in DT or
>> ACPI remapping tables, the guest can defer probing of the NIC until the
>> IOMMU is initialized.
>>
>> Thanks,
>> Jean
>
> Could you point me at the code you refer to here?
In drivers/base/dd.c, really_probe() calls dma_configure() before the
device driver's probe(). dma_configure() ends up calling either
of_dma_configure() or acpi_dma_configure(), which return -EPROBE_DEFER
if the device's IOMMU isn't yet available. In that case the device is
added to the deferred pending list.
After another device is successfully bound to a driver, all devices on
the pending list are retried (driver_deferred_probe_trigger()), and if
the dependency has been resolved, then dma_configure() succeeds.
Another method (used by Intel and AMD IOMMU drivers) is to initialize
the IOMMU as early as possible, after discovering it in the ACPI tables
and before probing other devices. This can't work for virtio-iommu
because the driver might be a module, in which case early init isn't
possible. We have to defer probe of all dependent devices until the
virtio and virtio-iommu modules are loaded.
Thanks,
Jean
^ permalink raw reply
* Re: [PATCH] gpu/drm/virtio/virtgpu_vq.c: Use kmem_cache_zalloc
From: Jani Nikula @ 2018-10-23 9:50 UTC (permalink / raw)
To: Souptick Joarder, Sabyasachi Gupta
Cc: airlied, linux-kernel, dri-devel, virtualization, Brajeswar Ghosh
In-Reply-To: <CAFqt6zbdxjUF4tEh8WXRZT-eo58sfw0tKa3DyxTXCesjEJkqfA@mail.gmail.com>
On Tue, 23 Oct 2018, Souptick Joarder <jrdr.linux@gmail.com> wrote:
> On Fri, Oct 19, 2018 at 9:30 PM Sabyasachi Gupta
> <sabyasachi.linux@gmail.com> wrote:
>>
>> Replaced kmem_cache_alloc + memset with kmem_cache_zalloc
>
> Put a new line gap in between these two lines and send v2.
Nah, the maintainers can trivially add the newline while
applying. Review is much more valuable than nitpicking on the commit
message.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>
>> Signed-off-by: Sabyasachi Gupta <sabyasachi.linux@gmail.com>
>> ---
>> drivers/gpu/drm/virtio/virtgpu_vq.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
>> index 020070d..e001b79 100644
>> --- a/drivers/gpu/drm/virtio/virtgpu_vq.c
>> +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
>> @@ -98,10 +98,9 @@ virtio_gpu_get_vbuf(struct virtio_gpu_device *vgdev,
>> {
>> struct virtio_gpu_vbuffer *vbuf;
>>
>> - vbuf = kmem_cache_alloc(vgdev->vbufs, GFP_KERNEL);
>> + vbuf = kmem_cache_zalloc(vgdev->vbufs, GFP_KERNEL);
>> if (!vbuf)
>> return ERR_PTR(-ENOMEM);
>> - memset(vbuf, 0, VBUFFER_SIZE);
>>
>> BUG_ON(size > MAX_INLINE_CMD_SIZE);
>> vbuf->buf = (void *)vbuf + sizeof(*vbuf);
>> --
>> 2.7.4
>>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply
* Re: [PATCH v37 0/3] Virtio-balloon: support free page reporting
From: Michael S. Tsirkin @ 2018-10-25 0:58 UTC (permalink / raw)
To: Wei Wang
Cc: yang.zhang.wz, virtio-dev, riel, quan.xu0, kvm, nilal,
liliang.opensource, linux-kernel, mhocko, linux-mm, pbonzini,
akpm, virtualization, torvalds, dgilbert
In-Reply-To: <1535333539-32420-1-git-send-email-wei.w.wang@intel.com>
On Mon, Aug 27, 2018 at 09:32:16AM +0800, Wei Wang wrote:
> The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT, implemented by this
> series enables the virtio-balloon driver to report hints of guest free
> pages to host. It can be used to accelerate virtual machine (VM) live
> migration. Here is an introduction of this usage:
>
> Live migration needs to transfer the VM's memory from the source machine
> to the destination round by round. For the 1st round, all the VM's memory
> is transferred. From the 2nd round, only the pieces of memory that were
> written by the guest (after the 1st round) are transferred. One method
> that is popularly used by the hypervisor to track which part of memory is
> written is to have the hypervisor write-protect all the guest memory.
>
> This feature enables the optimization by skipping the transfer of guest
> free pages during VM live migration. It is not concerned that the memory
> pages are used after they are given to the hypervisor as a hint of the
> free pages, because they will be tracked by the hypervisor and transferred
> in the subsequent round if they are used and written.
OK so it will be in linux-next. Now can I trouble you for a virtio spec
patch with the description please?
> * Tests
> 1 Test Environment
> Host: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
> Migration setup: migrate_set_speed 100G, migrate_set_downtime 400ms
>
> 2 Test Results (results are averaged over several repeated runs)
> 2.1 Guest setup: 8G RAM, 4 vCPU
> 2.1.1 Idle guest live migration time
> Optimization v.s. Legacy = 620ms vs 2970ms
> --> ~79% reduction
> 2.1.2 Guest live migration with Linux compilation workload
> (i.e. make bzImage -j4) running
> 1) Live Migration Time:
> Optimization v.s. Legacy = 2273ms v.s. 4502ms
> --> ~50% reduction
> 2) Linux Compilation Time:
> Optimization v.s. Legacy = 8min42s v.s. 8min43s
> --> no obvious difference
>
> 2.2 Guest setup: 128G RAM, 4 vCPU
> 2.2.1 Idle guest live migration time
> Optimization v.s. Legacy = 5294ms vs 41651ms
> --> ~87% reduction
> 2.2.2 Guest live migration with Linux compilation workload
> 1) Live Migration Time:
> Optimization v.s. Legacy = 8816ms v.s. 54201ms
> --> 84% reduction
> 2) Linux Compilation Time:
> Optimization v.s. Legacy = 8min30s v.s. 8min36s
> --> no obvious difference
>
> ChangeLog:
> v36->v37:
> - free the reported pages to mm when receives a DONE cmd from host.
> Please see patch 1's commit log for reasons. Please see patch 1's
> commit for detailed explanations.
>
> For ChangeLogs from v22 to v36, please reference
> https://lkml.org/lkml/2018/7/20/199
>
> For ChangeLogs before v21, please reference
> https://lwn.net/Articles/743660/
>
> Wei Wang (3):
> virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
> mm/page_poison: expose page_poisoning_enabled to kernel modules
> virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON
>
> drivers/virtio/virtio_balloon.c | 374 ++++++++++++++++++++++++++++++++----
> include/uapi/linux/virtio_balloon.h | 8 +
> mm/page_poison.c | 6 +
> 3 files changed, 355 insertions(+), 33 deletions(-)
>
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH v37 0/3] Virtio-balloon: support free page reporting
From: Wei Wang @ 2018-10-25 10:18 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: yang.zhang.wz, virtio-dev, riel, quan.xu0, kvm, nilal,
liliang.opensource, linux-kernel, mhocko, linux-mm, pbonzini,
akpm, virtualization, torvalds, dgilbert
In-Reply-To: <20181024205759-mutt-send-email-mst@kernel.org>
On 10/25/2018 08:58 AM, Michael S. Tsirkin wrote:
> On Mon, Aug 27, 2018 at 09:32:16AM +0800, Wei Wang wrote:
>> The new feature, VIRTIO_BALLOON_F_FREE_PAGE_HINT, implemented by this
>> series enables the virtio-balloon driver to report hints of guest free
>> pages to host. It can be used to accelerate virtual machine (VM) live
>> migration. Here is an introduction of this usage:
>>
>> Live migration needs to transfer the VM's memory from the source machine
>> to the destination round by round. For the 1st round, all the VM's memory
>> is transferred. From the 2nd round, only the pieces of memory that were
>> written by the guest (after the 1st round) are transferred. One method
>> that is popularly used by the hypervisor to track which part of memory is
>> written is to have the hypervisor write-protect all the guest memory.
>>
>> This feature enables the optimization by skipping the transfer of guest
>> free pages during VM live migration. It is not concerned that the memory
>> pages are used after they are given to the hypervisor as a hint of the
>> free pages, because they will be tracked by the hypervisor and transferred
>> in the subsequent round if they are used and written.
> OK so it will be in linux-next. Now can I trouble you for a virtio spec
> patch with the description please?
No problem, I'll start to patch the spec. Thanks!
Best,
Wei
^ permalink raw reply
* Re: PROPOSAL: Extend inline asm syntax with size spec
From: Borislav Petkov @ 2018-10-25 10:24 UTC (permalink / raw)
To: Segher Boessenkool, Ingo Molnar, Richard Biener, Michael Matz,
gcc, Nadav Amit, Ingo Molnar, linux-kernel, x86, Masahiro Yamada,
Sam Ravnborg, Alok Kataria, Christopher Li, Greg Kroah-Hartman,
H. Peter Anvin, Jan Beulich, Josh Poimboeuf, Juergen Gross,
Kate Stewart, Kees Cook, linux-sparse, Peter Zijlstra,
Philippe Ombredanne, Thomas Gleixner, virtualization
In-Reply-To: <20181013193335.GD31650@zn.tnic>
Ping.
This is a good point in time, methinks, where kernel folk on CC here
should have a look at this and speak up whether it is useful for us in
this form.
Frankly, I'm a bit unsure on the aspect of us using this and supporting
old compilers which don't have it and new compilers which do. Because
the old compilers should get to see the now upstreamed assembler macros
and the new compilers will simply inline the "asm volatile inline"
constructs. And how ugly that would become...
I guess we can try this with smaller macros first and keep them all
nicely hidden in header files.
On Sat, Oct 13, 2018 at 09:33:35PM +0200, Borislav Petkov wrote:
> Ok,
>
> with Segher's help I've been playing with his patch ontop of bleeding
> edge gcc 9 and here are my observations. Please double-check me for
> booboos so that they can be addressed while there's time.
>
> So here's what I see ontop of 4.19-rc7:
>
> First marked the alternative asm() as inline and undeffed the "inline"
> keyword. I need to do that because of the funky games we do with
> "inline" redefinitions in include/linux/compiler_types.h.
>
> And Segher hinted at either doing:
>
> asm volatile inline(...
>
> or
>
> asm volatile __inline__(...
>
> but both "inline" variants are defined as macros in that file.
>
> Which means we either need to #undef inline before using it in asm() or
> come up with something cleverer.
>
> Anyway, did this:
>
> ---
> diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h
> index 4cd6a3b71824..7c0639087da7 100644
> --- a/arch/x86/include/asm/alternative.h
> +++ b/arch/x86/include/asm/alternative.h
> @@ -165,11 +165,13 @@ static inline int alternatives_text_reserved(void *start, void *end)
> * For non barrier like inlines please define new variants
> * without volatile and memory clobber.
> */
> +
> +#undef inline
> #define alternative(oldinstr, newinstr, feature) \
> - asm volatile (ALTERNATIVE(oldinstr, newinstr, feature) : : : "memory")
> + asm volatile inline(ALTERNATIVE(oldinstr, newinstr, feature) : : : "memory")
>
> #define alternative_2(oldinstr, newinstr1, feature1, newinstr2, feature2) \
> - asm volatile(ALTERNATIVE_2(oldinstr, newinstr1, feature1, newinstr2, feature2) ::: "memory")
> + asm volatile inline(ALTERNATIVE_2(oldinstr, newinstr1, feature1, newinstr2, feature2) ::: "memory")
>
> /*
> * Alternative inline assembly with input.
> ---
>
> Build failed at link time with:
>
> arch/x86/boot/compressed/cmdline.o: In function `native_save_fl':
> cmdline.c:(.text+0x0): multiple definition of `native_save_fl'
> arch/x86/boot/compressed/misc.o:misc.c:(.text+0x1e0): first defined here
> arch/x86/boot/compressed/cmdline.o: In function `native_restore_fl':
> cmdline.c:(.text+0x10): multiple definition of `native_restore_fl'
> arch/x86/boot/compressed/misc.o:misc.c:(.text+0x1f0): first defined here
> arch/x86/boot/compressed/error.o: In function `native_save_fl':
> error.c:(.text+0x0): multiple definition of `native_save_fl'
>
> which I had to fix with this:
>
> ---
> diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
> index 15450a675031..0d772598c37c 100644
> --- a/arch/x86/include/asm/irqflags.h
> +++ b/arch/x86/include/asm/irqflags.h
> @@ -14,8 +14,7 @@
> */
>
> /* Declaration required for gcc < 4.9 to prevent -Werror=missing-prototypes */
> -extern inline unsigned long native_save_fl(void);
> -extern inline unsigned long native_save_fl(void)
> +static inline unsigned long native_save_fl(void)
> {
> unsigned long flags;
>
> @@ -33,8 +32,7 @@ ex
> ---
>
> That "extern inline" declaration looks fishy to me anyway, maybe not really
> needed ? Apparently, gcc < 4.9 complains with -Werror=missing-prototypes...
>
> Then the build worked and the results look like this:
>
> text data bss dec hex filename
> 17287384 5040656 2019532 24347572 17383b4 vmlinux-before
> 17288020 5040656 2015436 24344112 1737630 vmlinux-2nd-version
>
> so some inlining must be happening.
>
> Then I did this:
>
> ---
> diff --git a/arch/x86/lib/usercopy_64.c b/arch/x86/lib/usercopy_64.c
> index 9c5606d88f61..a0170344cf08 100644
> --- a/arch/x86/lib/usercopy_64.c
> +++ b/arch/x86/lib/usercopy_64.c
> @@ -20,7 +20,7 @@ unsigned long __clear_user(void __user *addr, unsigned long size)
> /* no memory constraint because it doesn't change any memory gcc knows
> about */
> stac();
> - asm volatile(
> + asm volatile inline(
> " testq %[size8],%[size8]\n"
> " jz 4f\n"
> "0: movq $0,(%[dst])\n"
> ---
>
> to force inlining of a somewhat bigger asm() statement. And yap, more
> got inlined:
>
> text data bss dec hex filename
> 17287384 5040656 2019532 24347572 17383b4 vmlinux-before
> 17288020 5040656 2015436 24344112 1737630 vmlinux-2nd-version
> 17288076 5040656 2015436 24344168 1737668 vmlinux-2nd-version__clear_user
>
> so more stuff gets inlined.
>
> Looking at the asm output, it had before:
>
> ---
> clear_user:
> # ./arch/x86/include/asm/current.h:15: return this_cpu_read_stable(current_task);
> #APP
> # 15 "./arch/x86/include/asm/current.h" 1
> movq %gs:current_task,%rax #, pfo_ret__
> # 0 "" 2
> # arch/x86/lib/usercopy_64.c:51: if (access_ok(VERIFY_WRITE, to, n))
> #NO_APP
> movq 2520(%rax), %rdx # pfo_ret___12->thread.addr_limit.seg, _1
> movq %rdi, %rax # to, tmp93
> addq %rsi, %rax # n, tmp93
> jc .L3 #,
> # arch/x86/lib/usercopy_64.c:51: if (access_ok(VERIFY_WRITE, to, n))
> cmpq %rax, %rdx # tmp93, _1
> jb .L3 #,
> # arch/x86/lib/usercopy_64.c:52: return __clear_user(to, n);
> jmp __clear_user #
> ---
>
> note the JMP to __clear_user. After marking the asm() in __clear_user() as
> inline, clear_user() inlines __clear_user() directly:
>
> ---
> clear_user:
> # ./arch/x86/include/asm/current.h:15: return this_cpu_read_stable(current_task);
> #APP
> # 15 "./arch/x86/include/asm/current.h" 1
> movq %gs:current_task,%rax #, pfo_ret__
> # 0 "" 2
> # arch/x86/lib/usercopy_64.c:51: if (access_ok(VERIFY_WRITE, to, n))
> #NO_APP
> movq 2520(%rax), %rdx # pfo_ret___12->thread.addr_limit.seg, _1
> movq %rdi, %rax # to, tmp95
> addq %rsi, %rax # n, tmp95
> jc .L8 #,
> # arch/x86/lib/usercopy_64.c:51: if (access_ok(VERIFY_WRITE, to, n))
> cmpq %rax, %rdx # tmp95, _1
> jb .L8 #,
> # ./arch/x86/include/asm/smap.h:58: alternative("", __stringify(__ASM_STAC), X86_FEATURE_SMAP);
> ...
>
> this last line is the stac() macro which gets inlined due to the
> alternative() inlined macro above.
>
> So I guess this all looks like what we wanted.
>
> And if this lands in gcc9, we would need to do a asm_volatile() macro
> which is defined differently based on the compiler used.
>
> Thoughts, suggestions, etc are most welcome.
>
> Thx.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
^ permalink raw reply
* Call for Papers - MICRADS 2019, Rio de Janeiro, Brazil
From: Marle @ 2018-10-25 16:43 UTC (permalink / raw)
To: virtualization
[-- Attachment #1.1: Type: text/plain, Size: 4867 bytes --]
** Proceedings by Springer
--------------------------------------
MICRADS´19 - The 2019 Multidisciplinary International Conference of Research Applied to Defense and Security
Rio de Janeiro, Brazil, 8 - 10 May 2019
http://www.micrads.org/ <http://www.micrads.org/>
------------------------------------------------------------------------------------------------------------------------------
Scope
MICRADS´19 - The 2019 Multidisciplinary International Conference of Research Applied to Defense and Security, to be held at Rio de Janeiro, Brazil, 8 - 10 May 2019, is an international forum for researchers and practitioners to present and discuss the most recent innovations, trends, results, experiences and concerns in the several perspectives of Defense and Security.
We are pleased to invite you to submit your papers to MICRADS´19. They can be written in English, Spanish or Portuguese. All submissions will be reviewed on the basis of relevance, originality, importance and clarity.
Topics
Submitted papers should be related with one or more of the main themes proposed for the Conference:
Area A: Systems, Communication and Defense
A1) Information and Communication Technology in Education
A2) Simulation and computer vision in military applications
A3) Analysis and Signal Processing
A4) Cybersecurity and Cyberdefense
A5) Computer Networks, Mobility and Pervasive Systems
Area B: Strategy and political-administrative vision in Defense
B1) Safety and Maritime Protection
B2) Strategy, Geopolitics and Oceanopolitics
B3) Planning, economy and logistics applied to Defense
B4) Leadership and e-leadership
B5) Military Marketing
B6) Health informatics in military applications
Area C: Engineering and technologies applied to Defense
C1) Wearable Technology and Assistance Devices
C2) Military Naval Engineering
C3) Weapons and Combat Systems
C4) Chemical, Biological and Nuclear Defense
C5) Defense Engineering (General)
Submission and Decision
Submitted papers (until 10-page limit) must comply with the format standard from Springer SIST series <https://www.springer.com/us/authors-editors/conference-proceedings/conference-proceedings-guidelines>, be written in English, Spanish or Portuguese, must not have been published before, not be under review for any other conference or publication and not include any information leading to the authors’ identification. Therefore, the authors’ names, affiliations and bibliographic references should not be included in the version for evaluation by the Scientific Committee. This information should only be included in the camera-ready version, saved in Word format and uploaded at the conference management system.
All papers will be subjected to a “blind review” by at least two members of the Scientific Committee.
Based on Scientific Committee evaluation, a paper can be rejected or accepted by the Conference Chairs. In the later case, it can be accepted as paper or poster.
The authors of papers accepted as posters must build and print a poster to be exhibited during the Conference. This poster must follow an A1 or A2 vertical format. The Conference can includes Work Sessions where these posters are presented and orally discussed, with a 7 minute limit per poster.
The authors of accepted papers will have 15 minutes to present their work in a Conference Work Session; approximately 5 minutes of discussion will follow each presentation.
Publication and Indexing
To ensure that an accepted paper is published, at least one of the authors must be fully registered by the 11 of February 2019, and the paper must comply with the suggested layout and page-limit (until 10 pages). Additionally, all recommended changes must be addressed by the authors before they submit the camera-ready version.
No more than one paper per registration will be published. An extra fee must be paid for publication of additional papers, with a maximum of one additional paper per registration. One registration permits only the participation of one author in the conference.
Papers can be written in English, Spanish or Portuguese. Accepted and registered papers written in English will be published in Proceedings by Springer, in a book of its SIST series, and will be submitted for indexing by ISI, SCOPUS, EI-Compendex, SpringerLink, and Google Scholar.
Important Dates
Paper Submission: December 17, 2018
Notification of Acceptance: January 28, 2019
Payment of Registration, to ensure the inclusion of an accepted paper in the conference proceedings: February 11, 2019.
Camera-ready Submission: February 11, 2019
WEBSITE of MICRADS'2019: http://www.micrads.org <http://www.micrads.org/>
---
This email has been checked for viruses by AVG.
https://www.avg.com
[-- Attachment #1.2: Type: text/html, Size: 7188 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v8] virtio_blk: add discard and write zeroes support
From: Paolo Bonzini @ 2018-10-25 23:28 UTC (permalink / raw)
To: Christoph Hellwig, Daniel Verkamp
Cc: Jens Axboe, Michael S. Tsirkin, virtualization, linux-block,
Stefan Hajnoczi, Changpeng Liu
In-Reply-To: <20181015092740.GA3964@infradead.org>
On 15/10/2018 11:27, Christoph Hellwig wrote:
> There is some issues in this spec. For one using the multiple ranges
> also for write zeroes is rather inefficient. Write zeroes really should
> use the same format as read and write.
What makes it inefficient?
> Second the unmap flag isn't properly specified at all, as nothing
> says the device may not unmap without the unmap flag. Please take
> a look at the SCSI or NVMe ѕpec for some guidance.
Thanks, I'll submit a patch for this.
Paolo
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox