* Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk
From: Jens Axboe @ 2017-11-20 19:42 UTC (permalink / raw)
To: Christian Borntraeger, Bart Van Assche,
virtualization@lists.linux-foundation.org,
linux-block@vger.kernel.org, mst@redhat.com, jasowang@redhat.com
In-Reply-To: <04526c98-ffc5-1eca-3aa8-50f9212c4323@de.ibm.com>
On 11/20/2017 12:29 PM, Christian Borntraeger wrote:
>
>
> On 11/20/2017 08:20 PM, Bart Van Assche wrote:
>> On Fri, 2017-11-17 at 15:42 +0100, Christian Borntraeger wrote:
>>> This is
>>>
>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1141) * are mapped to it.
>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1142) */
>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) &&
>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu));
>>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145)
>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /*
>>
>> Did you really try to figure out when the code that reported the warning
>> was introduced? I think that warning was introduced through the following
>> commit:
>
> This was more a cut'n'paste to show which warning triggered since line numbers are somewhat volatile.
>
>>
>> commit fd1270d5df6a005e1248e87042159a799cc4b2c9
>> Date: Wed Apr 16 09:23:48 2014 -0600
>>
>> blk-mq: don't use preempt_count() to check for right CPU
>>
>> UP or CONFIG_PREEMPT_NONE will return 0, and what we really
>> want to check is whether or not we are on the right CPU.
>> So don't make PREEMPT part of this, just test the CPU in
>> the mask directly.
>>
>> Anyway, I think that warning is appropriate and useful. So the next step
>> is to figure out what work item was involved and why that work item got
>> executed on the wrong CPU.
>
> It seems to be related to virtio-blk (is triggered by fio on such disks). Your comment basically
> says: "no this is not a known issue" then :-)
> I will try to take a dump to find out the work item
blk-mq does not attempt to freeze/sync existing work if a CPU goes away,
and we reconfigure the mappings. So I don't think the above is unexpected,
if you are doing CPU hot unplug while running a fio job.
While it's a bit annoying that we trigger the WARN_ON() for a condition
that can happen, we're basically interested in it if it triggers for
normal operations.
--
Jens Axboe
^ permalink raw reply
* Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk
From: Christian Borntraeger @ 2017-11-20 19:29 UTC (permalink / raw)
To: Bart Van Assche, virtualization@lists.linux-foundation.org,
linux-block@vger.kernel.org, mst@redhat.com, axboe@kernel.dk,
jasowang@redhat.com
In-Reply-To: <1511205644.2396.32.camel@wdc.com>
On 11/20/2017 08:20 PM, Bart Van Assche wrote:
> On Fri, 2017-11-17 at 15:42 +0100, Christian Borntraeger wrote:
>> This is
>>
>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1141) * are mapped to it.
>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1142) */
>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) &&
>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu));
>> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145)
>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /*
>
> Did you really try to figure out when the code that reported the warning
> was introduced? I think that warning was introduced through the following
> commit:
This was more a cut'n'paste to show which warning triggered since line numbers are somewhat volatile.
>
> commit fd1270d5df6a005e1248e87042159a799cc4b2c9
> Date: Wed Apr 16 09:23:48 2014 -0600
>
> blk-mq: don't use preempt_count() to check for right CPU
>
> UP or CONFIG_PREEMPT_NONE will return 0, and what we really
> want to check is whether or not we are on the right CPU.
> So don't make PREEMPT part of this, just test the CPU in
> the mask directly.
>
> Anyway, I think that warning is appropriate and useful. So the next step
> is to figure out what work item was involved and why that work item got
> executed on the wrong CPU.
It seems to be related to virtio-blk (is triggered by fio on such disks). Your comment basically
says: "no this is not a known issue" then :-)
I will try to take a dump to find out the work item
^ permalink raw reply
* Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk
From: Bart Van Assche @ 2017-11-20 19:20 UTC (permalink / raw)
To: virtualization@lists.linux-foundation.org,
linux-block@vger.kernel.org, mst@redhat.com,
borntraeger@de.ibm.com, axboe@kernel.dk, jasowang@redhat.com
In-Reply-To: <9c5eec5d-f542-4d76-6933-6fe31203ce09@de.ibm.com>
On Fri, 2017-11-17 at 15:42 +0100, Christian Borntraeger wrote:
> This is
>
> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1141) * are mapped to it.
> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1142) */
> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) &&
> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu));
> 6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145)
> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /*
Did you really try to figure out when the code that reported the warning
was introduced? I think that warning was introduced through the following
commit:
commit fd1270d5df6a005e1248e87042159a799cc4b2c9
Date: Wed Apr 16 09:23:48 2014 -0600
blk-mq: don't use preempt_count() to check for right CPU
UP or CONFIG_PREEMPT_NONE will return 0, and what we really
want to check is whether or not we are on the right CPU.
So don't make PREEMPT part of this, just test the CPU in
the mask directly.
Anyway, I think that warning is appropriate and useful. So the next step
is to figure out what work item was involved and why that work item got
executed on the wrong CPU.
Bart.
^ permalink raw reply
* Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
From: Daniel Lezcano @ 2017-11-20 18:01 UTC (permalink / raw)
To: Quan Xu, Thomas Gleixner, Peter Zijlstra
Cc: Yang Zhang, Len Brown, kvm, linux-doc, x86, LKML, virtualization,
Kyle Huey, Ingo Molnar, Borislav Petkov, Quan Xu, Andy Lutomirski,
H. Peter Anvin, linux-fsdevel, xen-devel, Tom Lendacky,
Tobias Klauser
In-Reply-To: <5deab1e9-cef2-0511-09d8-cef8e4323f02@gmail.com>
On 20/11/2017 08:05, Quan Xu wrote:
[ ... ]
>>>> But the irq_timings stuff is heading into the same direction, with a
>>>> more
>>>> complex prediction logic which should tell you pretty good how long
>>>> that
>>>> idle period is going to be and in case of an interrupt heavy workload
>>>> this
>>>> would skip the extra work of stopping and restarting the tick and
>>>> provide a
>>>> very good input into a polling decision.
>>>
>>> interesting. I have tested with IRQ_TIMINGS related code, which seems
>>> not working so far.
>> I don't know how you tested it, can you elaborate what you meant by
>> "seems not working so far" ?
>
> Daniel, I tried to enable IRQ_TIMINGS* manually. used
> irq_timings_next_event()
> to return estimation of the earliest interrupt. However I got a constant.
The irq timings gives you an indication of the next interrupt deadline.
This information is a piece of the puzzle, you need to combine it with
the next timer expiration, and the next scheduling event. Then take the
earliest event in a timeline basis.
Using the trivial scheme above will work well with workload like videos
or mp3 but will fail as soon as the interrupts are not coming in a
regular basis and this is where the pattern recognition algorithm must act.
>> There are still some work to do to be more efficient. The prediction
>> based on the irq timings is all right if the interrupts have a simple
>> periodicity. But as soon as there is a pattern, the current code can't
>> handle it properly and does bad predictions.
>>
>> I'm working on a self-learning pattern detection which is too heavy for
>> the kernel, and with it we should be able to detect properly the
>> patterns and re-ajust the period if it changes. I'm in the process of
>> making it suitable for kernel code (both math and perf).
>>
>> One improvement which can be done right now and which can help you is
>> the interrupts rate on the CPU. It is possible to compute it and that
>> will give an accurate information for the polling decision.
>>
>>
> As tglx said, talk to each other / work together to make it usable for
> all use cases.
> could you share how to enable it to get the interrupts rate on the CPU?
> I can try it
> in cloud scenario. of course, I'd like to work with you to improve it.
Sure, I will be glad if we can collaborate. I have some draft code but
before sharing it I would like we define what is the rate and what kind
of information we expect to infer from it. From my point of view it is a
value indicating the interrupt period per CPU, a short value indicates a
high number of interrupts on the CPU.
This value must decay with the time, the question here is what decay
function we apply to the rate from the last timestamp ?
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v3] virtio_balloon: include disk/file caches memory statistics
From: Tomáš Golembiovský @ 2017-11-20 14:06 UTC (permalink / raw)
To: linux-mm, virtio-dev, qemu-devel, kvm, virtualization
Cc: Rik van Riel, Michael S. Tsirkin, Gal Hammer, Shaohua Li,
Huang Ying
In-Reply-To: <2e8c12f5242bcf755a33ee3a0e9ef94339d1808c.1510487579.git.tgolembi@redhat.com>
On Sun, 12 Nov 2017 13:05:38 +0100
Tomáš Golembiovský <tgolembi@redhat.com> wrote:
> Add a new field VIRTIO_BALLOON_S_CACHES to virtio_balloon memory
> statistics protocol. The value represents all disk/file caches.
>
> In this case it corresponds to the sum of values
> Buffers+Cached+SwapCached from /proc/meminfo.
>
> Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
> ---
> drivers/virtio/virtio_balloon.c | 4 ++++
> include/uapi/linux/virtio_balloon.h | 3 ++-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
ping
--
Tomáš Golembiovský <tgolembi@redhat.com>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
From: Wei Wang @ 2017-11-20 11:42 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: yang.zhang.wz, kvm, penguin-kernel, liliang.opensource,
qemu-devel, virtualization, linux-mm, aarcange, virtio-dev,
mawilcox, willy, quan.xu, Nitesh Narayan Lal, Rik van Riel,
cornelia.huck, mhocko, linux-kernel, amit.shah, pbonzini, akpm,
mgorman
In-Reply-To: <20171113192309-mutt-send-email-mst@kernel.org>
On 11/14/2017 01:32 AM, Michael S. Tsirkin wrote:
> You should Cc Nitesh who is working on a related feature.
OK, I'll do. We have two more issues which haven't been discussed yet,
please have a check below.
>
> On Mon, Nov 13, 2017 at 06:34:48PM +0800, Wei Wang wrote:
>> Ping for comments, thanks.
>>
>> On 11/03/2017 04:13 PM, Wei Wang wrote:
>>> +static void virtballoon_cmd_report_free_page_start(struct virtio_balloon *vb)
>>> +{
>>> + unsigned long flags;
>>> +
>>> + vb->report_free_page_stop = false;
> this flag is used a lot outside any locks. Why is this safe?
> Please add some comments explaining access to this flag.
I will revert the logic as suggested: vb->report_free_page. Also plan to
simplify its usage as below.
The flag is set or cleared in the config handler according to the
new_cmd_id given
by the host:
new_cmd_id=0: WRITE_ONCE(vb->report_free_page,
false); // stop reporting
new_cmd_id != old_cmd_id: WRITE_ONCE(vb->report_free_page, true); //
start reporting
The flag is read by virtio_balloon_send_free_pages() - the callback to
report free pages:
if (!READ_ONCE(vb->report_free_page))
return false;
I don't find where it could be unsafe then (the flag is written by the
config handler only).
>
>>> +}
>>> +
>>> static inline s64 towards_target(struct virtio_balloon *vb)
>>> {
>>> s64 target;
>>> @@ -597,42 +673,147 @@ static void update_balloon_size_func(struct work_struct *work)
>>> queue_work(system_freezable_wq, work);
>>> }
>>> -static int init_vqs(struct virtio_balloon *vb)
>>> +static bool virtio_balloon_send_free_pages(void *opaque, unsigned long pfn,
>>> + unsigned long nr_pages)
>>> {
>>> - struct virtqueue *vqs[3];
>>> - vq_callback_t *callbacks[] = { balloon_ack, balloon_ack, stats_request };
>>> - static const char * const names[] = { "inflate", "deflate", "stats" };
>>> - int err, nvqs;
>>> + struct virtio_balloon *vb = (struct virtio_balloon *)opaque;
>>> + void *addr = (void *)pfn_to_kaddr(pfn);
> How do we know all free pages have a kaddr?
For x86_64, it works well since the kernel has all the physical memory
mapped already. But for 32-bit kernel, yes, the high memory usually
isn't mapped and thus no kaddr. Essentially, this pfn_to_kaddr convert
isn't necessary, we do it here because the current API that virtio has
is based on "struct scatterlist", which takes a kaddr, and this kaddr is
then convert back to physical address in virtqueue_add() when assigning
to desc->addr.
I think a better solution would be to add a new API, which directly
assigns the caller's guest physical address to desc->addr, similar to
the previous implementation "add_one_chunk()"
(https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg02452.html).
But we can change that to a general virtio API:
virtqueue_add_one_desc(struct virtqueue *_vq, u64 base_addr, u32 size,
bool in_desc, void *data);
What do you think?
Best,
Wei
^ permalink raw reply
* Re: [Xen-devel] [PATCH RFC v3 0/6] x86/idle: add halt poll support
From: Quan Xu @ 2017-11-20 7:18 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Quan Xu
Cc: Yang Zhang, kvm, linux-doc, x86, linux-kernel, virtualization,
linux-fsdevel, xen-devel
In-Reply-To: <20171115213131.GB21113@char.us.oracle.com>
On 2017-11-16 05:31, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 13, 2017 at 06:05:59PM +0800, Quan Xu wrote:
>> From: Yang Zhang <yang.zhang.wz@gmail.com>
>>
>> Some latency-intensive workload have seen obviously performance
>> drop when running inside VM. The main reason is that the overhead
>> is amplified when running inside VM. The most cost I have seen is
>> inside idle path.
> Meaning an VMEXIT b/c it is an 'halt' operation ? And then going
> back in guest (VMRESUME) takes time. And hence your latency gets
> all whacked b/c of this?
Konrad, I can't follow 'b/c' here.. sorry.
> So if I understand - you want to use your _full_ timeslice (of the guest)
> without ever (or as much as possible) to go in the hypervisor?
as much as possible.
> Which means in effect you don't care about power-saving or CPUfreq
> savings, you just want to eat the full CPU for snack?
actually, we care about power-saving. The poll duration is
self-tuning, otherwise it is almost as the same as
'halt=poll'. Also we always sent out with CPU usage of benchmark
netperf/ctxsw. We got much more
performance with limited promotion of CPU usage.
>> This patch introduces a new mechanism to poll for a while before
>> entering idle state. If schedule is needed during poll, then we
>> don't need to goes through the heavy overhead path.
> Schedule of what? The guest or the host?
rescheduled of guest scheduler..
it is the guest.
Quan
Alibaba Cloud
>
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
From: Quan Xu @ 2017-11-20 7:05 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Peter Zijlstra
Cc: Yang Zhang, Len Brown, kvm, linux-doc, x86, LKML, virtualization,
Kyle Huey, Ingo Molnar, Borislav Petkov, Quan Xu, Andy Lutomirski,
H. Peter Anvin, linux-fsdevel, xen-devel, Tom Lendacky,
Tobias Klauser
In-Reply-To: <93a26005-aa37-82e1-5c04-a82c9027bac8@linaro.org>
On 2017-11-16 17:45, Daniel Lezcano wrote:
> On 16/11/2017 10:12, Quan Xu wrote:
>>
>> On 2017-11-16 06:03, Thomas Gleixner wrote:
>>> On Wed, 15 Nov 2017, Peter Zijlstra wrote:
>>>
>>>> On Mon, Nov 13, 2017 at 06:06:02PM +0800, Quan Xu wrote:
>>>>> From: Yang Zhang <yang.zhang.wz@gmail.com>
>>>>>
>>>>> Implement a generic idle poll which resembles the functionality
>>>>> found in arch/. Provide weak arch_cpu_idle_poll function which
>>>>> can be overridden by the architecture code if needed.
>>>> No, we want less of those magic hooks, not more.
>>>>
>>>>> Interrupts arrive which may not cause a reschedule in idle loops.
>>>>> In KVM guest, this costs several VM-exit/VM-entry cycles, VM-entry
>>>>> for interrupts and VM-exit immediately. Also this becomes more
>>>>> expensive than bare metal. Add a generic idle poll before enter
>>>>> real idle path. When a reschedule event is pending, we can bypass
>>>>> the real idle path.
>>>> Why not do a HV specific idle driver?
>>> If I understand the problem correctly then he wants to avoid the heavy
>>> lifting in tick_nohz_idle_enter() in the first place, but there is
>>> already
>>> an interesting quirk there which makes it exit early. See commit
>>> 3c5d92a0cfb5 ("nohz: Introduce arch_needs_cpu"). The reason for this
>>> commit
>>> looks similar. But lets not proliferate that. I'd rather see that go
>>> away.
>> agreed.
>>
>> Even we can get more benifit than commit 3c5d92a0cfb5 ("nohz: Introduce
>> arch_needs_cpu")
>> in kvm guest. I won't proliferate that..
>>
>>> But the irq_timings stuff is heading into the same direction, with a more
>>> complex prediction logic which should tell you pretty good how long that
>>> idle period is going to be and in case of an interrupt heavy workload
>>> this
>>> would skip the extra work of stopping and restarting the tick and
>>> provide a
>>> very good input into a polling decision.
>>
>> interesting. I have tested with IRQ_TIMINGS related code, which seems
>> not working so far.
> I don't know how you tested it, can you elaborate what you meant by
> "seems not working so far" ?
Daniel, I tried to enable IRQ_TIMINGS* manually. used
irq_timings_next_event()
to return estimation of the earliest interrupt. However I got a constant.
> There are still some work to do to be more efficient. The prediction
> based on the irq timings is all right if the interrupts have a simple
> periodicity. But as soon as there is a pattern, the current code can't
> handle it properly and does bad predictions.
>
> I'm working on a self-learning pattern detection which is too heavy for
> the kernel, and with it we should be able to detect properly the
> patterns and re-ajust the period if it changes. I'm in the process of
> making it suitable for kernel code (both math and perf).
>
> One improvement which can be done right now and which can help you is
> the interrupts rate on the CPU. It is possible to compute it and that
> will give an accurate information for the polling decision.
>
>
As tglx said, talk to each other / work together to make it usable for
all use cases.
could you share how to enable it to get the interrupts rate on the CPU?
I can try it
in cloud scenario. of course, I'd like to work with you to improve it.
Quan
Alibaba Cloud
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [virtio-dev] Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
From: Michael S. Tsirkin @ 2017-11-19 15:11 UTC (permalink / raw)
To: Wang, Wei W
Cc: aarcange@redhat.com, virtio-dev@lists.oasis-open.org,
cornelia.huck@de.ibm.com, kvm@vger.kernel.org,
mawilcox@microsoft.com, penguin-kernel@I-love.SAKURA.ne.jp,
liliang.opensource@gmail.com, qemu-devel@nongnu.org,
willy@infradead.org, linux-kernel@vger.kernel.org,
mhocko@kernel.org, linux-mm@kvack.org, pbonzini@redhat.com,
amit.shah@redhat.com, quan.xu@aliyun.com, yang.zhang.wz@gmail.com
In-Reply-To: <286AC319A985734F985F78AFA26841F73936A8E7@shsmsx102.ccr.corp.intel.com>
On Sat, Nov 18, 2017 at 05:22:28AM +0000, Wang, Wei W wrote:
> On Friday, November 17, 2017 8:45 PM, Michael S. Tsirkin wrote:
> > On Fri, Nov 17, 2017 at 07:35:03PM +0800, Wei Wang wrote:
> > > On 11/16/2017 09:27 PM, Wei Wang wrote:
> > > > On 11/16/2017 04:32 AM, Michael S. Tsirkin wrote:
> > > > > On Fri, Nov 03, 2017 at 04:13:06PM +0800, Wei Wang wrote:
> > > > > > Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature
> > > > > > indicates the support of reporting hints of guest free pages to
> > > > > > the host via virtio-balloon. The host requests the guest to
> > > > > > report the free pages by sending commands via the virtio-balloon
> > configuration registers.
> > > > > >
> > > > > > When the guest starts to report, the first element added to the
> > > > > > free page vq is a sequence id of the start reporting command.
> > > > > > The id is given by the host, and it indicates whether the
> > > > > > following free pages correspond to the command. For example, the
> > > > > > host may stop the report and start again with a new command id.
> > > > > > The obsolete pages for the previous start command can be
> > > > > > detected by the id dismatching on the host. The id is added to
> > > > > > the vq using an output buffer, and the free pages are added to
> > > > > > the vq using input buffer.
> > > > > >
> > > > > > Here are some explainations about the added configuration registers:
> > > > > > - host2guest_cmd: a register used by the host to send commands
> > > > > > to the guest.
> > > > > > - guest2host_cmd: written by the guest to ACK to the host about
> > > > > > the commands that have been received. The host will clear the
> > > > > > corresponding bits on the host2guest_cmd register. The guest
> > > > > > also uses this register to send commands to the host (e.g. when finish
> > free page reporting).
> > > > > > - free_page_cmd_id: the sequence id of the free page report
> > > > > > command given by the host.
> > > > > >
> > > > > > Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> > > > > > Signed-off-by: Liang Li <liang.z.li@intel.com>
> > > > > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > > > > Cc: Michal Hocko <mhocko@kernel.org>
> > > > > > ---
> > > > > >
> > > > > > +
> > > > > > +static void report_free_page(struct work_struct *work) {
> > > > > > + struct virtio_balloon *vb;
> > > > > > +
> > > > > > + vb = container_of(work, struct virtio_balloon,
> > > > > > report_free_page_work);
> > > > > > + report_free_page_cmd_id(vb);
> > > > > > + walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages);
> > > > > > + /*
> > > > > > + * The last few free page blocks that were added may not reach the
> > > > > > + * batch size, but need a kick to notify the device to
> > > > > > handle them.
> > > > > > + */
> > > > > > + virtqueue_kick(vb->free_page_vq);
> > > > > > + report_free_page_end(vb);
> > > > > > +}
> > > > > > +
> > > > > I think there's an issue here: if pages are poisoned and
> > > > > hypervisor subsequently drops them, testing them after allocation
> > > > > will trigger a false positive.
> > > > >
> > > > > The specific configuration:
> > > > >
> > > > > PAGE_POISONING on
> > > > > PAGE_POISONING_NO_SANITY off
> > > > > PAGE_POISONING_ZERO off
> > > > >
> > > > >
> > > > > Solutions:
> > > > > 1. disable the feature in that configuration
> > > > > suggested as an initial step
> > > >
> > > > Thanks for the finding.
> > > > Similar to this option: I'm thinking could we make
> > > > walk_free_mem_block() simply return if that option is on?
> > > > That is, at the beginning of the function:
> > > > if (!page_poisoning_enabled())
> > > > return;
> > > >
> > >
> > >
> > > Thought about it more, I think it would be better to put this logic to
> > > virtio_balloon:
> > >
> > > send_free_page_cmd_id(vb, &vb->start_cmd_id);
> > > if (page_poisoning_enabled() &&
> > > !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY))
> > > walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages);
> > > send_free_page_cmd_id(vb, &vb->stop_cmd_id);
> > >
> > >
> > > walk_free_mem_block() should be a more generic API, and this potential
> > > page poisoning issue is specific to live migration which is only one
> > > use case of this function, so I think it is better to handle it in the
> > > special use case itself.
> > >
> > > Best,
> > > Wei
> > >
> >
> > It's a quick work-around but it doesn't make me very happy.
> >
> > AFAIK e.g. RHEL has a debug kernel with poisoning enabled.
> > If this never uses free page hinting at all, it will be much less useful for
> > debugging guests.
> >
>
> I understand your concern. I think people who use debugging guests
> don't regard performance as the first priority, and most vendors
> usually wouldn't use debugging guests for their products.
And when one of these crashes but only after migration what do you do? A
very common step is for Red Hat support is to ask people to try
reproducing with a debug build.
IOT being able to debug guests is important, if a debugging guest takes
a significantly different path from non-debug one, we have a problem.
>
> How about taking it as the initial solution? We can exploit more
> solutions after this series is done.
>
> Best,
> Wei
I think it's fine as a separate patch.
--
MST
^ permalink raw reply
* Call for papers - MICRADS 2018 - Salinas, Ecuador
From: MarLe @ 2017-11-19 0:47 UTC (permalink / raw)
To: virtualization
[-- Attachment #1: Type: text/plain, Size: 4778 bytes --]
* Proceedings by Springer and indexed by Scopus, etc.
---------------------------------------------------------------------------------------------------------------------------
MICRADS´18 - The 2018 Multidisciplinary International Conference of Research Applied to Defense and Security
Salinas, Ecuador, 18 - 20 April 2018
http://www.micrads.org/
------------------------------------------------------------------------------------------------------------------------------------
SCOPE
MICRADS´18 - The 2018 Multidisciplinary International Conference of Research Applied to Defense and Security, to be held at Salinas, Ecuador, 18 - 20 April 2018, 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´18. 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:
A) Information and Communication Technology in Education;
B) Computer vision in military applications;
C) Engineering Analysis and Signal Processing;
D) Cybersecurity and Cyberdefense;
E) Maritime Security and Safety;
F) Strategy, geopolitics and Oceanopolitics;
G) Defense planning;
H) Leadership (e-leadership);
I) Defense Economics;
J) Defense Logistics;
K) Health informatics in military applications;
L) Simulation in Military Application;
M) Computer Networks, Mobility and Pervasive Systems;
N) Military Marketing;
O) Military Physical Training;
P) Assistive Devices and Wearable Technology;
Q) Naval and Military Engineering;
R) Weapons and Combat Systems;
S) Operational Oceanography.
SUBMISSION AND DECISION
Submitted papers (until 6-page limit) must comply with the format standard (http://www.micrads.org/images/Templates.rar), 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 “double-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 3 of February 2018, 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 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, SpingerLink, and Google Scholar.
IMPORTANT DATES
Paper Submission: January 14, 2018
Notification of Acceptance: February 14, 2018
Payment of Registration, to ensure the inclusion of an accepted paper in the conference proceedings: February 18, 2018.
Camera-ready Submission: February 21, 2018
-
Website o MICRADS'18: http://www.micrads.org/
-------
---
This email has been checked for viruses by AVG.
http://www.avg.com
[-- 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 03/13] x86/paravirt: Convert native patch assembly code strings to macros
From: Josh Poimboeuf @ 2017-11-18 13:17 UTC (permalink / raw)
To: Juergen Gross
Cc: Boris Ostrovsky, Rusty Russell, Mike Galbraith, Thomas Gleixner,
xen-devel, Peter Zijlstra, Jiri Slaby, x86, linux-kernel,
Sasha Levin, Borislav Petkov, Andy Lutomirski, H. Peter Anvin,
live-patching, Alok Kataria, virtualization, Linus Torvalds,
Ingo Molnar
In-Reply-To: <4022805e-38b2-869c-a766-b7e5026a263e@suse.com>
On Sat, Nov 18, 2017 at 11:20:06AM +0100, Juergen Gross wrote:
> >>>> +#define NATIVE_ZERO "xor " _REG_ARG1 ", " _REG_ARG1
> >>>
> >>> NATIVE_ZERO_OUT
> >>>
> >>> I guess. NATIVE_ZERO reads like the native representation of 0 :-)
> >>
> >> NATIVE_ZERO_ARG1?
> >
> > On a slight tangent, does anybody know why it zeros the arg?
>
> Why are _you_ asking? You've introduced it.
So I did. Touché!
> > The only place it's used is here:
> >
> > #if defined(CONFIG_PARAVIRT_SPINLOCKS)
> > DEF_NATIVE(pv_lock_ops, queued_spin_unlock, NATIVE_QUEUED_SPIN_UNLOCK);
> > DEF_NATIVE(pv_lock_ops, vcpu_is_preempted, NATIVE_ZERO);
> > #endif
> >
> > Isn't that a bug? Seems like it should _return_ zero. Zeroing the arg
> > shouldn't have any effect.
>
> Right. Before that patch it _did_ return zero instead of zeroing arg1.
Oops!
> > If I'm right, we could call it NATIVE_FALSE.
>
> I'd prefer NATIVE_ZERO, as it will be usable for non-boolean cases, too.
NATIVE_ZERO works for me.
--
Josh
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros
From: Juergen Gross @ 2017-11-18 10:20 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Boris Ostrovsky, Rusty Russell, Mike Galbraith, Thomas Gleixner,
xen-devel, Peter Zijlstra, Jiri Slaby, x86, linux-kernel,
Sasha Levin, Borislav Petkov, Andy Lutomirski, H. Peter Anvin,
live-patching, Alok Kataria, virtualization, Linus Torvalds,
Ingo Molnar
In-Reply-To: <20171117194231.576qqr3wnkgowdln@treble>
On 17/11/17 20:42, Josh Poimboeuf wrote:
> On Fri, Nov 17, 2017 at 08:10:13PM +0100, Juergen Gross wrote:
>> On 17/11/17 19:07, Borislav Petkov wrote:
>>> On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote:
>>>> Convert the hard-coded native patch assembly code strings to macros to
>>>> facilitate sharing common code between 32-bit and 64-bit.
>>>>
>>>> These macros will also be used by a future patch which requires the GCC
>>>> extended asm syntax of two '%' characters instead of one when specifying
>>>> a register name.
>>>>
>>>> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
>>>> ---
>>>> arch/x86/include/asm/special_insns.h | 24 ++++++++++++++++++++++++
>>>> arch/x86/kernel/paravirt_patch_32.c | 21 +++++++++++----------
>>>> arch/x86/kernel/paravirt_patch_64.c | 29 +++++++++++++++--------------
>>>> 3 files changed, 50 insertions(+), 24 deletions(-)
>>>>
>>>> diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h
>>>> index ac402c6fc24b..0549c5f2c1b3 100644
>>>> --- a/arch/x86/include/asm/special_insns.h
>>>> +++ b/arch/x86/include/asm/special_insns.h
>>>> @@ -6,6 +6,30 @@
>>>>
>>>> #include <asm/nops.h>
>>>>
>>>> +#ifdef CONFIG_X86_64
>>>> +# define _REG_ARG1 "%rdi"
>>>> +# define NATIVE_IDENTITY_32 "mov %edi, %eax"
>>>
>>> Yeah, that "identity" looks strange. How about NATIVE_NOOP and
>>> NATIVE_NOOP_32 ?
>>
>> Those are not NOPs. They return the identical value which was passed to
>> them. So identity isn't a bad name after all.
>
> Right, like the math identity function:
>
> https://en.wikipedia.org/wiki/Identity_function
>
>>>> +# define NATIVE_USERGS_SYSRET64 "swapgs; sysretq"
>>>> +#else
>>>> +# define _REG_ARG1 "%eax"
>>>> +#endif
>>>> +
>>>> +#define _REG_RET "%" _ASM_AX
>>>> +
>>>> +#define NATIVE_ZERO "xor " _REG_ARG1 ", " _REG_ARG1
>>>
>>> NATIVE_ZERO_OUT
>>>
>>> I guess. NATIVE_ZERO reads like the native representation of 0 :-)
>>
>> NATIVE_ZERO_ARG1?
>
> On a slight tangent, does anybody know why it zeros the arg?
Why are _you_ asking? You've introduced it.
> The only place it's used is here:
>
> #if defined(CONFIG_PARAVIRT_SPINLOCKS)
> DEF_NATIVE(pv_lock_ops, queued_spin_unlock, NATIVE_QUEUED_SPIN_UNLOCK);
> DEF_NATIVE(pv_lock_ops, vcpu_is_preempted, NATIVE_ZERO);
> #endif
>
> Isn't that a bug? Seems like it should _return_ zero. Zeroing the arg
> shouldn't have any effect.
Right. Before that patch it _did_ return zero instead of zeroing arg1.
> If I'm right, we could call it NATIVE_FALSE.
I'd prefer NATIVE_ZERO, as it will be usable for non-boolean cases, too.
Juergen
^ permalink raw reply
* RE: [virtio-dev] Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
From: Wang, Wei W @ 2017-11-18 5:22 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: aarcange@redhat.com, virtio-dev@lists.oasis-open.org,
cornelia.huck@de.ibm.com, kvm@vger.kernel.org,
mawilcox@microsoft.com, penguin-kernel@I-love.SAKURA.ne.jp,
liliang.opensource@gmail.com, qemu-devel@nongnu.org,
willy@infradead.org, linux-kernel@vger.kernel.org,
mhocko@kernel.org, linux-mm@kvack.org, pbonzini@redhat.com,
amit.shah@redhat.com, quan.xu@aliyun.com, yang.zhang.wz@gmail.com
In-Reply-To: <20171117144253-mutt-send-email-mst@kernel.org>
On Friday, November 17, 2017 8:45 PM, Michael S. Tsirkin wrote:
> On Fri, Nov 17, 2017 at 07:35:03PM +0800, Wei Wang wrote:
> > On 11/16/2017 09:27 PM, Wei Wang wrote:
> > > On 11/16/2017 04:32 AM, Michael S. Tsirkin wrote:
> > > > On Fri, Nov 03, 2017 at 04:13:06PM +0800, Wei Wang wrote:
> > > > > Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature
> > > > > indicates the support of reporting hints of guest free pages to
> > > > > the host via virtio-balloon. The host requests the guest to
> > > > > report the free pages by sending commands via the virtio-balloon
> configuration registers.
> > > > >
> > > > > When the guest starts to report, the first element added to the
> > > > > free page vq is a sequence id of the start reporting command.
> > > > > The id is given by the host, and it indicates whether the
> > > > > following free pages correspond to the command. For example, the
> > > > > host may stop the report and start again with a new command id.
> > > > > The obsolete pages for the previous start command can be
> > > > > detected by the id dismatching on the host. The id is added to
> > > > > the vq using an output buffer, and the free pages are added to
> > > > > the vq using input buffer.
> > > > >
> > > > > Here are some explainations about the added configuration registers:
> > > > > - host2guest_cmd: a register used by the host to send commands
> > > > > to the guest.
> > > > > - guest2host_cmd: written by the guest to ACK to the host about
> > > > > the commands that have been received. The host will clear the
> > > > > corresponding bits on the host2guest_cmd register. The guest
> > > > > also uses this register to send commands to the host (e.g. when finish
> free page reporting).
> > > > > - free_page_cmd_id: the sequence id of the free page report
> > > > > command given by the host.
> > > > >
> > > > > Signed-off-by: Wei Wang <wei.w.wang@intel.com>
> > > > > Signed-off-by: Liang Li <liang.z.li@intel.com>
> > > > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > > > Cc: Michal Hocko <mhocko@kernel.org>
> > > > > ---
> > > > >
> > > > > +
> > > > > +static void report_free_page(struct work_struct *work) {
> > > > > + struct virtio_balloon *vb;
> > > > > +
> > > > > + vb = container_of(work, struct virtio_balloon,
> > > > > report_free_page_work);
> > > > > + report_free_page_cmd_id(vb);
> > > > > + walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages);
> > > > > + /*
> > > > > + * The last few free page blocks that were added may not reach the
> > > > > + * batch size, but need a kick to notify the device to
> > > > > handle them.
> > > > > + */
> > > > > + virtqueue_kick(vb->free_page_vq);
> > > > > + report_free_page_end(vb);
> > > > > +}
> > > > > +
> > > > I think there's an issue here: if pages are poisoned and
> > > > hypervisor subsequently drops them, testing them after allocation
> > > > will trigger a false positive.
> > > >
> > > > The specific configuration:
> > > >
> > > > PAGE_POISONING on
> > > > PAGE_POISONING_NO_SANITY off
> > > > PAGE_POISONING_ZERO off
> > > >
> > > >
> > > > Solutions:
> > > > 1. disable the feature in that configuration
> > > > suggested as an initial step
> > >
> > > Thanks for the finding.
> > > Similar to this option: I'm thinking could we make
> > > walk_free_mem_block() simply return if that option is on?
> > > That is, at the beginning of the function:
> > > if (!page_poisoning_enabled())
> > > return;
> > >
> >
> >
> > Thought about it more, I think it would be better to put this logic to
> > virtio_balloon:
> >
> > send_free_page_cmd_id(vb, &vb->start_cmd_id);
> > if (page_poisoning_enabled() &&
> > !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY))
> > walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages);
> > send_free_page_cmd_id(vb, &vb->stop_cmd_id);
> >
> >
> > walk_free_mem_block() should be a more generic API, and this potential
> > page poisoning issue is specific to live migration which is only one
> > use case of this function, so I think it is better to handle it in the
> > special use case itself.
> >
> > Best,
> > Wei
> >
>
> It's a quick work-around but it doesn't make me very happy.
>
> AFAIK e.g. RHEL has a debug kernel with poisoning enabled.
> If this never uses free page hinting at all, it will be much less useful for
> debugging guests.
>
I understand your concern. I think people who use debugging guests don't regard performance as the first priority, and most vendors usually wouldn't use debugging guests for their products.
How about taking it as the initial solution? We can exploit more solutions after this series is done.
Best,
Wei
^ permalink raw reply
* Re: [PATCH 10/13] x86/alternative: Support indirect call replacement
From: H. Peter Anvin @ 2017-11-17 19:52 UTC (permalink / raw)
To: Josh Poimboeuf, x86
Cc: Juergen Gross, Rusty Russell, Peter Zijlstra, Jiri Slaby,
Boris Ostrovsky, Mike Galbraith, linux-kernel, Sasha Levin,
Chris Wright, Thomas Gleixner, Andy Lutomirski, xen-devel,
Borislav Petkov, live-patching, Alok Kataria, virtualization,
Linus Torvalds, Ingo Molnar
In-Reply-To: <efabcfb022d29fb0a9ccb39380623573555c2bcb.1507128293.git.jpoimboe@redhat.com>
On 10/04/17 08:58, Josh Poimboeuf wrote:
> Add alternative patching support for replacing an instruction with an
> indirect call. This will be needed for the paravirt alternatives.
I have a patchset that generalizes the alternatives in what I think is a
more robust way. I really, really want to get rid of these hacks. Let
me clean it up an post it...
-hpa
^ permalink raw reply
* Re: [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros
From: Josh Poimboeuf @ 2017-11-17 19:42 UTC (permalink / raw)
To: Juergen Gross
Cc: Boris Ostrovsky, Rusty Russell, Mike Galbraith, Thomas Gleixner,
xen-devel, Peter Zijlstra, Jiri Slaby, x86, linux-kernel,
Sasha Levin, Chris Wright, Borislav Petkov, Andy Lutomirski,
H. Peter Anvin, live-patching, Alok Kataria, virtualization,
Linus Torvalds, Ingo Molnar
In-Reply-To: <a9531df0-0a48-e695-a05a-56e654f9dfbb@suse.com>
On Fri, Nov 17, 2017 at 08:10:13PM +0100, Juergen Gross wrote:
> On 17/11/17 19:07, Borislav Petkov wrote:
> > On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote:
> >> Convert the hard-coded native patch assembly code strings to macros to
> >> facilitate sharing common code between 32-bit and 64-bit.
> >>
> >> These macros will also be used by a future patch which requires the GCC
> >> extended asm syntax of two '%' characters instead of one when specifying
> >> a register name.
> >>
> >> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> >> ---
> >> arch/x86/include/asm/special_insns.h | 24 ++++++++++++++++++++++++
> >> arch/x86/kernel/paravirt_patch_32.c | 21 +++++++++++----------
> >> arch/x86/kernel/paravirt_patch_64.c | 29 +++++++++++++++--------------
> >> 3 files changed, 50 insertions(+), 24 deletions(-)
> >>
> >> diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h
> >> index ac402c6fc24b..0549c5f2c1b3 100644
> >> --- a/arch/x86/include/asm/special_insns.h
> >> +++ b/arch/x86/include/asm/special_insns.h
> >> @@ -6,6 +6,30 @@
> >>
> >> #include <asm/nops.h>
> >>
> >> +#ifdef CONFIG_X86_64
> >> +# define _REG_ARG1 "%rdi"
> >> +# define NATIVE_IDENTITY_32 "mov %edi, %eax"
> >
> > Yeah, that "identity" looks strange. How about NATIVE_NOOP and
> > NATIVE_NOOP_32 ?
>
> Those are not NOPs. They return the identical value which was passed to
> them. So identity isn't a bad name after all.
Right, like the math identity function:
https://en.wikipedia.org/wiki/Identity_function
> >> +# define NATIVE_USERGS_SYSRET64 "swapgs; sysretq"
> >> +#else
> >> +# define _REG_ARG1 "%eax"
> >> +#endif
> >> +
> >> +#define _REG_RET "%" _ASM_AX
> >> +
> >> +#define NATIVE_ZERO "xor " _REG_ARG1 ", " _REG_ARG1
> >
> > NATIVE_ZERO_OUT
> >
> > I guess. NATIVE_ZERO reads like the native representation of 0 :-)
>
> NATIVE_ZERO_ARG1?
On a slight tangent, does anybody know why it zeros the arg?
The only place it's used is here:
#if defined(CONFIG_PARAVIRT_SPINLOCKS)
DEF_NATIVE(pv_lock_ops, queued_spin_unlock, NATIVE_QUEUED_SPIN_UNLOCK);
DEF_NATIVE(pv_lock_ops, vcpu_is_preempted, NATIVE_ZERO);
#endif
Isn't that a bug? Seems like it should _return_ zero. Zeroing the arg
shouldn't have any effect.
If I'm right, we could call it NATIVE_FALSE.
--
Josh
^ permalink raw reply
* Re: [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros
From: Juergen Gross @ 2017-11-17 19:10 UTC (permalink / raw)
To: Borislav Petkov, Josh Poimboeuf
Cc: Boris Ostrovsky, Rusty Russell, Mike Galbraith, xen-devel,
Peter Zijlstra, Jiri Slaby, x86, linux-kernel, Sasha Levin,
Chris Wright, Thomas Gleixner, Andy Lutomirski, H. Peter Anvin,
live-patching, Alok Kataria, virtualization, Linus Torvalds,
Ingo Molnar
In-Reply-To: <20171117180713.e4up3dwrszpatka6@pd.tnic>
On 17/11/17 19:07, Borislav Petkov wrote:
> On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote:
>> Convert the hard-coded native patch assembly code strings to macros to
>> facilitate sharing common code between 32-bit and 64-bit.
>>
>> These macros will also be used by a future patch which requires the GCC
>> extended asm syntax of two '%' characters instead of one when specifying
>> a register name.
>>
>> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
>> ---
>> arch/x86/include/asm/special_insns.h | 24 ++++++++++++++++++++++++
>> arch/x86/kernel/paravirt_patch_32.c | 21 +++++++++++----------
>> arch/x86/kernel/paravirt_patch_64.c | 29 +++++++++++++++--------------
>> 3 files changed, 50 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h
>> index ac402c6fc24b..0549c5f2c1b3 100644
>> --- a/arch/x86/include/asm/special_insns.h
>> +++ b/arch/x86/include/asm/special_insns.h
>> @@ -6,6 +6,30 @@
>>
>> #include <asm/nops.h>
>>
>> +#ifdef CONFIG_X86_64
>> +# define _REG_ARG1 "%rdi"
>> +# define NATIVE_IDENTITY_32 "mov %edi, %eax"
>
> Yeah, that "identity" looks strange. How about NATIVE_NOOP and
> NATIVE_NOOP_32 ?
Those are not NOPs. They return the identical value which was passed to
them. So identity isn't a bad name after all.
>
>> +# define NATIVE_USERGS_SYSRET64 "swapgs; sysretq"
>> +#else
>> +# define _REG_ARG1 "%eax"
>> +#endif
>> +
>> +#define _REG_RET "%" _ASM_AX
>> +
>> +#define NATIVE_ZERO "xor " _REG_ARG1 ", " _REG_ARG1
>
> NATIVE_ZERO_OUT
>
> I guess. NATIVE_ZERO reads like the native representation of 0 :-)
NATIVE_ZERO_ARG1?
Juergen
^ permalink raw reply
* [RFC PATCH v2 5/5] ACPI/IORT: Move IORT to the ACPI folder
From: Jean-Philippe Brucker @ 2017-11-17 18:52 UTC (permalink / raw)
To: iommu, devel, linux-acpi, kvm, kvmarm, virtualization, virtio-dev
Cc: Jayachandran.Nair, lorenzo.pieralisi, ashok.raj, mst,
marc.zyngier, will.deacon, rjw, robert.moore, eric.auger,
lv.zheng, sudeep.holla, lenb, robin.murphy, joro, hanjun.guo
In-Reply-To: <20171117185211.32593-1-jean-philippe.brucker@arm.com>
IORT can be used (by QEMU) to describe a virtual topology containing an
architecture-agnostic paravirtualized device. The rationale behind this
blasphemy is explained in patch 4/5.
In order to build IORT for x86 systems, the driver has to be moved outside
of arm64/. Since there is nothing specific to arm64 in the driver, it
simply requires moving Makefile and Kconfig entries.
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
---
drivers/acpi/Kconfig | 3 +++
drivers/acpi/Makefile | 1 +
drivers/acpi/arm64/Kconfig | 3 ---
drivers/acpi/arm64/Makefile | 1 -
drivers/acpi/{arm64 => }/iort.c | 0
5 files changed, 4 insertions(+), 4 deletions(-)
rename drivers/acpi/{arm64 => }/iort.c (100%)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 5b1938f4b626..ce40275646c8 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -536,4 +536,7 @@ if ARM64
source "drivers/acpi/arm64/Kconfig"
endif
+config ACPI_IORT
+ bool
+
endif # ACPI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index cd1abc9bc325..689c470c013b 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -112,3 +112,4 @@ video-objs += acpi_video.o video_detect.o
obj-y += dptf/
obj-$(CONFIG_ARM64) += arm64/
+obj-$(CONFIG_ACPI_IORT) += iort.o
diff --git a/drivers/acpi/arm64/Kconfig b/drivers/acpi/arm64/Kconfig
index 5a6f80fce0d6..403f917ab274 100644
--- a/drivers/acpi/arm64/Kconfig
+++ b/drivers/acpi/arm64/Kconfig
@@ -2,8 +2,5 @@
# ACPI Configuration for ARM64
#
-config ACPI_IORT
- bool
-
config ACPI_GTDT
bool
diff --git a/drivers/acpi/arm64/Makefile b/drivers/acpi/arm64/Makefile
index 1017def2ea12..47925dc6cfc8 100644
--- a/drivers/acpi/arm64/Makefile
+++ b/drivers/acpi/arm64/Makefile
@@ -1,2 +1 @@
-obj-$(CONFIG_ACPI_IORT) += iort.o
obj-$(CONFIG_ACPI_GTDT) += gtdt.o
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/iort.c
similarity index 100%
rename from drivers/acpi/arm64/iort.c
rename to drivers/acpi/iort.c
--
2.14.3
^ permalink raw reply related
* [RFC PATCH v2 4/5] ACPI/IORT: Support paravirtualized IOMMU
From: Jean-Philippe Brucker @ 2017-11-17 18:52 UTC (permalink / raw)
To: iommu, devel, linux-acpi, kvm, kvmarm, virtualization, virtio-dev
Cc: Jayachandran.Nair, lorenzo.pieralisi, ashok.raj, mst,
marc.zyngier, will.deacon, rjw, robert.moore, eric.auger,
lv.zheng, sudeep.holla, lenb, robin.murphy, joro, hanjun.guo
In-Reply-To: <20171117185211.32593-1-jean-philippe.brucker@arm.com>
To describe the virtual topology in relation to a virtio-iommu device,
ACPI-based systems use a "paravirtualized IOMMU" IORT node. Add support
for it.
This is a RFC because the IORT specification doesn't describe the
paravirtualized node at the moment, it is only provided as an example in
the virtio-iommu spec. What we need to do first is confirm that x86
kernels are able to use the IORT driver with the virtio-iommu. There isn't
anything specific to arm64 in the driver but there might be other blockers
we're not aware of (I know for example that x86 also requires custom DMA
ops rather than iommu-dma ones, but it's unrelated) so this needs to be
tested on the x86 prototype.
Rationale: virtio-iommu requires an ACPI table to be passed between host
and guest that describes its relation to PCI and platform endpoints in the
virtual system. A table that maps PCI RIDs and integrated devices to IOMMU
device IDs, telling the IOMMU driver which endpoints it manages.
As far as I'm aware, there are three existing tables that solve this
problem: Intel DMAR, AMD IVRS and ARM IORT. The first two are specific to
Intel VT-d and AMD IOMMU respectively, while the third describes multiple
remapping devices -- currently only ARM IOMMUs and MSI controllers, but it
is easy to extend.
IORT table and drivers are easiest to extend and they do the job, so
rather than introducing a fourth solution to solve a generic problem,
reuse what exists.
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
---
drivers/acpi/arm64/iort.c | 95 +++++++++++++++++++++++++++++++++++++++++++----
drivers/iommu/Kconfig | 1 +
include/acpi/actbl2.h | 18 ++++++++-
3 files changed, 106 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index fde279b0a6d8..c7132e4a0560 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -29,7 +29,8 @@
#define IORT_TYPE_MASK(type) (1 << (type))
#define IORT_MSI_TYPE (1 << ACPI_IORT_NODE_ITS_GROUP)
#define IORT_IOMMU_TYPE ((1 << ACPI_IORT_NODE_SMMU) | \
- (1 << ACPI_IORT_NODE_SMMU_V3))
+ (1 << ACPI_IORT_NODE_SMMU_V3) | \
+ (1 << ACPI_IORT_NODE_PARAVIRT))
/* Until ACPICA headers cover IORT rev. C */
#ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
@@ -616,6 +617,8 @@ static inline bool iort_iommu_driver_enabled(u8 type)
return IS_BUILTIN(CONFIG_ARM_SMMU_V3);
case ACPI_IORT_NODE_SMMU:
return IS_BUILTIN(CONFIG_ARM_SMMU);
+ case ACPI_IORT_NODE_PARAVIRT:
+ return IS_BUILTIN(CONFIG_VIRTIO_IOMMU);
default:
pr_warn("IORT node type %u does not describe an SMMU\n", type);
return false;
@@ -1062,6 +1065,48 @@ static bool __init arm_smmu_is_coherent(struct acpi_iort_node *node)
return smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK;
}
+static int __init paravirt_count_resources(struct acpi_iort_node *node)
+{
+ struct acpi_iort_pviommu *pviommu;
+
+ pviommu = (struct acpi_iort_pviommu *)node->node_data;
+
+ /* Mem + IRQs */
+ return 1 + pviommu->interrupt_count;
+}
+
+static void __init paravirt_init_resources(struct resource *res,
+ struct acpi_iort_node *node)
+{
+ int i;
+ int num_res = 0;
+ int hw_irq, trigger;
+ struct acpi_iort_pviommu *pviommu;
+
+ pviommu = (struct acpi_iort_pviommu *)node->node_data;
+
+ res[num_res].start = pviommu->base_address;
+ res[num_res].end = pviommu->base_address + pviommu->span - 1;
+ res[num_res].flags = IORESOURCE_MEM;
+ num_res++;
+
+ for (i = 0; i < pviommu->interrupt_count; i++) {
+ hw_irq = IORT_IRQ_MASK(pviommu->interrupts[i]);
+ trigger = IORT_IRQ_TRIGGER_MASK(pviommu->interrupts[i]);
+
+ acpi_iort_register_irq(hw_irq, "pviommu", trigger, &res[num_res++]);
+ }
+}
+
+static bool __init paravirt_is_coherent(struct acpi_iort_node *node)
+{
+ struct acpi_iort_pviommu *pviommu;
+
+ pviommu = (struct acpi_iort_pviommu *)node->node_data;
+
+ return pviommu->flags & ACPI_IORT_NODE_PV_CACHE_COHERENT;
+}
+
struct iort_iommu_config {
const char *name;
int (*iommu_init)(struct acpi_iort_node *node);
@@ -1088,6 +1133,13 @@ static const struct iort_iommu_config iort_arm_smmu_cfg __initconst = {
.iommu_init_resources = arm_smmu_init_resources
};
+static const struct iort_iommu_config iort_paravirt_cfg __initconst = {
+ .name = "pviommu",
+ .iommu_is_coherent = paravirt_is_coherent,
+ .iommu_count_resources = paravirt_count_resources,
+ .iommu_init_resources = paravirt_init_resources
+};
+
static __init
const struct iort_iommu_config *iort_get_iommu_cfg(struct acpi_iort_node *node)
{
@@ -1096,18 +1148,22 @@ const struct iort_iommu_config *iort_get_iommu_cfg(struct acpi_iort_node *node)
return &iort_arm_smmu_v3_cfg;
case ACPI_IORT_NODE_SMMU:
return &iort_arm_smmu_cfg;
+ case ACPI_IORT_NODE_PARAVIRT:
+ return &iort_paravirt_cfg;
default:
return NULL;
}
}
/**
- * iort_add_smmu_platform_device() - Allocate a platform device for SMMU
- * @node: Pointer to SMMU ACPI IORT node
+ * iort_add_iommu_platform_device() - Allocate a platform device for an IOMMU
+ * @node: Pointer to IOMMU ACPI IORT node
+ * @name: Base name of the device
*
* Returns: 0 on success, <0 failure
*/
-static int __init iort_add_smmu_platform_device(struct acpi_iort_node *node)
+static int __init iort_add_iommu_platform_device(struct acpi_iort_node *node,
+ const char *name)
{
struct fwnode_handle *fwnode;
struct platform_device *pdev;
@@ -1119,7 +1175,7 @@ static int __init iort_add_smmu_platform_device(struct acpi_iort_node *node)
if (!ops)
return -ENODEV;
- pdev = platform_device_alloc(ops->name, PLATFORM_DEVID_AUTO);
+ pdev = platform_device_alloc(name, PLATFORM_DEVID_AUTO);
if (!pdev)
return -ENOMEM;
@@ -1189,6 +1245,28 @@ static int __init iort_add_smmu_platform_device(struct acpi_iort_node *node)
return ret;
}
+static int __init iort_add_smmu_platform_device(struct acpi_iort_node *node)
+{
+ const struct iort_iommu_config *ops = iort_get_iommu_cfg(node);
+
+ if (!ops)
+ return -ENODEV;
+
+ return iort_add_iommu_platform_device(node, ops->name);
+}
+
+static int __init iort_add_paravirt_platform_device(struct acpi_iort_node *node)
+{
+ struct acpi_iort_pviommu *pviommu;
+
+ pviommu = (struct acpi_iort_pviommu *)node->node_data;
+
+ if (WARN_ON(pviommu->model != ACPI_IORT_NODE_PV_VIRTIO_IOMMU))
+ return -ENODEV;
+
+ return iort_add_iommu_platform_device(node, "virtio-mmio");
+}
+
static bool __init iort_enable_acs(struct acpi_iort_node *iort_node)
{
if (iort_node->type == ACPI_IORT_NODE_PCI_ROOT_COMPLEX) {
@@ -1250,7 +1328,8 @@ static void __init iort_init_platform_devices(void)
acs_enabled = iort_enable_acs(iort_node);
if ((iort_node->type == ACPI_IORT_NODE_SMMU) ||
- (iort_node->type == ACPI_IORT_NODE_SMMU_V3)) {
+ (iort_node->type == ACPI_IORT_NODE_SMMU_V3) ||
+ (iort_node->type == ACPI_IORT_NODE_PARAVIRT)) {
fwnode = acpi_alloc_fwnode_static();
if (!fwnode)
@@ -1258,7 +1337,9 @@ static void __init iort_init_platform_devices(void)
iort_set_fwnode(iort_node, fwnode);
- ret = iort_add_smmu_platform_device(iort_node);
+ ret = iort_node->type == ACPI_IORT_NODE_PARAVIRT ?
+ iort_add_paravirt_platform_device(iort_node) :
+ iort_add_smmu_platform_device(iort_node);
if (ret) {
iort_delete_fwnode(iort_node);
acpi_free_fwnode_static(fwnode);
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 7271e59e8b23..3e28a5d682c3 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -409,6 +409,7 @@ config VIRTIO_IOMMU
select IOMMU_API
select INTERVAL_TREE
select ARM_DMA_USE_IOMMU if ARM
+ select ACPI_IORT
help
Para-virtualised IOMMU driver with virtio.
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index 686b6f8c09dc..23ae5bbc36d1 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -696,7 +696,8 @@ enum acpi_iort_node_type {
ACPI_IORT_NODE_NAMED_COMPONENT = 0x01,
ACPI_IORT_NODE_PCI_ROOT_COMPLEX = 0x02,
ACPI_IORT_NODE_SMMU = 0x03,
- ACPI_IORT_NODE_SMMU_V3 = 0x04
+ ACPI_IORT_NODE_SMMU_V3 = 0x04,
+ ACPI_IORT_NODE_PARAVIRT = 0x05,
};
struct acpi_iort_id_mapping {
@@ -824,6 +825,21 @@ struct acpi_iort_smmu_v3 {
#define ACPI_IORT_SMMU_V3_HTTU_OVERRIDE (1<<1)
#define ACPI_IORT_SMMU_V3_PXM_VALID (1<<3)
+struct acpi_iort_pviommu {
+ u64 base_address;
+ u64 span;
+ u32 model;
+ u32 flags;
+ u32 interrupt_count;
+ u64 interrupts[];
+};
+
+enum acpi_iort_paravirt_node_model {
+ ACPI_IORT_NODE_PV_VIRTIO_IOMMU = 0x00,
+};
+
+#define ACPI_IORT_NODE_PV_CACHE_COHERENT (1<<0)
+
/*******************************************************************************
*
* IVRS - I/O Virtualization Reporting Structure
--
2.14.3
^ permalink raw reply related
* [RFC PATCH v2 3/5] iommu/virtio-iommu: Add event queue
From: Jean-Philippe Brucker @ 2017-11-17 18:52 UTC (permalink / raw)
To: iommu, devel, linux-acpi, kvm, kvmarm, virtualization, virtio-dev
Cc: Jayachandran.Nair, lorenzo.pieralisi, ashok.raj, mst,
marc.zyngier, will.deacon, rjw, robert.moore, eric.auger,
lv.zheng, sudeep.holla, lenb, robin.murphy, joro, hanjun.guo
In-Reply-To: <20171117185211.32593-1-jean-philippe.brucker@arm.com>
The event queue offers a way for the device to report access faults from
devices. It is implemented on virtqueue #1, whenever the host needs to
signal a fault it fills one of the buffers offered by the guest and
interrupts it.
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
---
drivers/iommu/virtio-iommu.c | 138 ++++++++++++++++++++++++++++++++++----
include/uapi/linux/virtio_iommu.h | 18 +++++
2 files changed, 142 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index 79e0add94e05..fe0d449bf489 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -30,6 +30,12 @@
#define MSI_IOVA_BASE 0x8000000
#define MSI_IOVA_LENGTH 0x100000
+enum viommu_vq_idx {
+ VIOMMU_REQUEST_VQ = 0,
+ VIOMMU_EVENT_VQ = 1,
+ VIOMMU_NUM_VQS = 2,
+};
+
struct viommu_dev {
struct iommu_device iommu;
struct device *dev;
@@ -37,7 +43,7 @@ struct viommu_dev {
struct ida domain_ids;
- struct virtqueue *vq;
+ struct virtqueue *vqs[VIOMMU_NUM_VQS];
/* Serialize anything touching the request queue */
spinlock_t request_lock;
@@ -84,6 +90,15 @@ struct viommu_request {
struct list_head list;
};
+#define VIOMMU_FAULT_RESV_MASK 0xffffff00
+
+struct viommu_event {
+ union {
+ u32 head;
+ struct virtio_iommu_fault fault;
+ };
+};
+
#define to_viommu_domain(domain) container_of(domain, struct viommu_domain, domain)
/* Virtio transport */
@@ -160,12 +175,13 @@ static int viommu_receive_resp(struct viommu_dev *viommu, int nr_sent,
unsigned int len;
int nr_received = 0;
struct viommu_request *req, *pending;
+ struct virtqueue *vq = viommu->vqs[VIOMMU_REQUEST_VQ];
pending = list_first_entry_or_null(sent, struct viommu_request, list);
if (WARN_ON(!pending))
return 0;
- while ((req = virtqueue_get_buf(viommu->vq, &len)) != NULL) {
+ while ((req = virtqueue_get_buf(vq, &len)) != NULL) {
if (req != pending) {
dev_warn(viommu->dev, "discarding stale request\n");
continue;
@@ -202,6 +218,7 @@ static int _viommu_send_reqs_sync(struct viommu_dev *viommu,
* dies.
*/
unsigned long timeout_ms = 1000;
+ struct virtqueue *vq = viommu->vqs[VIOMMU_REQUEST_VQ];
*nr_sent = 0;
@@ -211,15 +228,14 @@ static int _viommu_send_reqs_sync(struct viommu_dev *viommu,
sg[0] = &req->top;
sg[1] = &req->bottom;
- ret = virtqueue_add_sgs(viommu->vq, sg, 1, 1, req,
- GFP_ATOMIC);
+ ret = virtqueue_add_sgs(vq, sg, 1, 1, req, GFP_ATOMIC);
if (ret)
break;
list_add_tail(&req->list, &pending);
}
- if (i && !virtqueue_kick(viommu->vq))
+ if (i && !virtqueue_kick(vq))
return -EPIPE;
timeout = ktime_add_ms(ktime_get(), timeout_ms * i);
@@ -554,6 +570,70 @@ static int viommu_probe_endpoint(struct viommu_dev *viommu, struct device *dev)
return 0;
}
+static int viommu_fault_handler(struct viommu_dev *viommu,
+ struct virtio_iommu_fault *fault)
+{
+ char *reason_str;
+
+ u8 reason = fault->reason;
+ u32 flags = le32_to_cpu(fault->flags);
+ u32 endpoint = le32_to_cpu(fault->endpoint);
+ u64 address = le64_to_cpu(fault->address);
+
+ switch (reason) {
+ case VIRTIO_IOMMU_FAULT_R_DOMAIN:
+ reason_str = "domain";
+ break;
+ case VIRTIO_IOMMU_FAULT_R_MAPPING:
+ reason_str = "page";
+ break;
+ case VIRTIO_IOMMU_FAULT_R_UNKNOWN:
+ default:
+ reason_str = "unknown";
+ break;
+ }
+
+ /* TODO: find EP by ID and report_iommu_fault */
+ if (flags & VIRTIO_IOMMU_FAULT_F_ADDRESS)
+ dev_err_ratelimited(viommu->dev, "%s fault from EP %u at %#llx [%s%s%s]\n",
+ reason_str, endpoint, address,
+ flags & VIRTIO_IOMMU_FAULT_F_READ ? "R" : "",
+ flags & VIRTIO_IOMMU_FAULT_F_WRITE ? "W" : "",
+ flags & VIRTIO_IOMMU_FAULT_F_EXEC ? "X" : "");
+ else
+ dev_err_ratelimited(viommu->dev, "%s fault from EP %u\n",
+ reason_str, endpoint);
+
+ return 0;
+}
+
+static void viommu_event_handler(struct virtqueue *vq)
+{
+ int ret;
+ unsigned int len;
+ struct scatterlist sg[1];
+ struct viommu_event *evt;
+ struct viommu_dev *viommu = vq->vdev->priv;
+
+ while ((evt = virtqueue_get_buf(vq, &len)) != NULL) {
+ if (len > sizeof(*evt)) {
+ dev_err(viommu->dev,
+ "invalid event buffer (len %u != %zu)\n",
+ len, sizeof(*evt));
+ } else if (!(evt->head & VIOMMU_FAULT_RESV_MASK)) {
+ viommu_fault_handler(viommu, &evt->fault);
+ }
+
+ sg_init_one(sg, evt, sizeof(*evt));
+ ret = virtqueue_add_inbuf(vq, sg, 1, evt, GFP_ATOMIC);
+ if (ret)
+ dev_err(viommu->dev, "could not add event buffer\n");
+ }
+
+ if (!virtqueue_kick(vq))
+ dev_err(viommu->dev, "kick failed\n");
+}
+
/* IOMMU API */
static bool viommu_capable(enum iommu_cap cap)
@@ -938,19 +1018,44 @@ static struct iommu_ops viommu_ops = {
.put_resv_regions = viommu_put_resv_regions,
};
-static int viommu_init_vq(struct viommu_dev *viommu)
+static int viommu_init_vqs(struct viommu_dev *viommu)
{
struct virtio_device *vdev = dev_to_virtio(viommu->dev);
- const char *name = "request";
- void *ret;
+ const char *names[] = { "request", "event" };
+ vq_callback_t *callbacks[] = {
+ NULL, /* No async requests */
+ viommu_event_handler,
+ };
+
+ return virtio_find_vqs(vdev, VIOMMU_NUM_VQS, viommu->vqs, callbacks,
+ names, NULL);
+}
- ret = virtio_find_single_vq(vdev, NULL, name);
- if (IS_ERR(ret)) {
- dev_err(viommu->dev, "cannot find VQ\n");
- return PTR_ERR(ret);
+static int viommu_fill_evtq(struct viommu_dev *viommu)
+{
+ int i, ret;
+ struct scatterlist sg[1];
+ struct viommu_event *evts;
+ struct virtqueue *vq = viommu->vqs[VIOMMU_EVENT_VQ];
+ size_t nr_evts = min_t(size_t, PAGE_SIZE / sizeof(struct viommu_event),
+ viommu->vqs[VIOMMU_EVENT_VQ]->num_free);
+
+ evts = devm_kmalloc_array(viommu->dev, nr_evts, sizeof(*evts),
+ GFP_KERNEL);
+ if (!evts)
+ return -ENOMEM;
+
+ for (i = 0; i < nr_evts; i++) {
+ sg_init_one(sg, &evts[i], sizeof(*evts));
+ ret = virtqueue_add_inbuf(vq, sg, 1, &evts[i], GFP_KERNEL);
+ if (ret)
+ return ret;
}
- viommu->vq = ret;
+ if (!virtqueue_kick(vq))
+ return -EPIPE;
+
+ dev_info(viommu->dev, "%zu event buffers\n", nr_evts);
return 0;
}
@@ -973,7 +1078,7 @@ static int viommu_probe(struct virtio_device *vdev)
viommu->dev = dev;
viommu->vdev = vdev;
- ret = viommu_init_vq(viommu);
+ ret = viommu_init_vqs(viommu);
if (ret)
goto err_free_viommu;
@@ -1014,6 +1119,11 @@ static int viommu_probe(struct virtio_device *vdev)
virtio_device_ready(vdev);
+ /* Populate the event queue with buffers */
+ ret = viommu_fill_evtq(viommu);
+ if (ret)
+ goto err_free_viommu;
+
ret = iommu_device_sysfs_add(&viommu->iommu, dev, NULL, "%s",
virtio_bus_name(vdev));
if (ret)
diff --git a/include/uapi/linux/virtio_iommu.h b/include/uapi/linux/virtio_iommu.h
index eec90a2ab547..b57543b4145b 100644
--- a/include/uapi/linux/virtio_iommu.h
+++ b/include/uapi/linux/virtio_iommu.h
@@ -174,4 +174,22 @@ union virtio_iommu_req {
struct virtio_iommu_req_probe probe;
};
+/* Fault types */
+#define VIRTIO_IOMMU_FAULT_R_UNKNOWN 0
+#define VIRTIO_IOMMU_FAULT_R_DOMAIN 1
+#define VIRTIO_IOMMU_FAULT_R_MAPPING 2
+
+#define VIRTIO_IOMMU_FAULT_F_READ (1 << 0)
+#define VIRTIO_IOMMU_FAULT_F_WRITE (1 << 1)
+#define VIRTIO_IOMMU_FAULT_F_EXEC (1 << 2)
+#define VIRTIO_IOMMU_FAULT_F_ADDRESS (1 << 8)
+
+struct virtio_iommu_fault {
+ __u8 reason;
+ __u8 padding[3];
+ __le32 flags;
+ __le32 endpoint;
+ __le64 address;
+} __packed;
+
#endif
--
2.14.3
^ permalink raw reply related
* [RFC PATCH v2 2/5] iommu/virtio-iommu: Add probe request
From: Jean-Philippe Brucker @ 2017-11-17 18:52 UTC (permalink / raw)
To: iommu, devel, linux-acpi, kvm, kvmarm, virtualization, virtio-dev
Cc: Jayachandran.Nair, lorenzo.pieralisi, ashok.raj, mst,
marc.zyngier, will.deacon, rjw, robert.moore, eric.auger,
lv.zheng, sudeep.holla, lenb, robin.murphy, joro, hanjun.guo
In-Reply-To: <20171117185211.32593-1-jean-philippe.brucker@arm.com>
When the device offers the probe feature, send a probe request for each
device managed by the IOMMU. Extract RESV_MEM information. When we
encounter a MSI doorbell region, set it up as a IOMMU_RESV_MSI region.
This will tell other subsystems that there is no need to map the MSI
doorbell in the virtio-iommu, because MSIs bypass it.
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
---
drivers/iommu/virtio-iommu.c | 165 ++++++++++++++++++++++++++++++++++++--
include/uapi/linux/virtio_iommu.h | 37 +++++++++
2 files changed, 195 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
index feb8c8925c3a..79e0add94e05 100644
--- a/drivers/iommu/virtio-iommu.c
+++ b/drivers/iommu/virtio-iommu.c
@@ -45,6 +45,7 @@ struct viommu_dev {
struct iommu_domain_geometry geometry;
u64 pgsize_bitmap;
u8 domain_bits;
+ u32 probe_size;
};
struct viommu_mapping {
@@ -72,6 +73,7 @@ struct viommu_domain {
struct viommu_endpoint {
struct viommu_dev *viommu;
struct viommu_domain *vdomain;
+ struct list_head resv_regions;
};
struct viommu_request {
@@ -139,6 +141,10 @@ static int viommu_get_req_size(struct viommu_dev *viommu,
case VIRTIO_IOMMU_T_UNMAP:
size = sizeof(r->unmap);
break;
+ case VIRTIO_IOMMU_T_PROBE:
+ *bottom += viommu->probe_size;
+ size = sizeof(r->probe) + *bottom;
+ break;
default:
return -EINVAL;
}
@@ -448,6 +454,106 @@ static int viommu_replay_mappings(struct viommu_domain *vdomain)
return ret;
}
+static int viommu_add_resv_mem(struct viommu_endpoint *vdev,
+ struct virtio_iommu_probe_resv_mem *mem,
+ size_t len)
+{
+ struct iommu_resv_region *region = NULL;
+ unsigned long prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+
+ u64 addr = le64_to_cpu(mem->addr);
+ u64 size = le64_to_cpu(mem->size);
+
+ if (len < sizeof(*mem))
+ return -EINVAL;
+
+ switch (mem->subtype) {
+ case VIRTIO_IOMMU_RESV_MEM_T_MSI:
+ region = iommu_alloc_resv_region(addr, size, prot,
+ IOMMU_RESV_MSI);
+ break;
+ case VIRTIO_IOMMU_RESV_MEM_T_RESERVED:
+ default:
+ region = iommu_alloc_resv_region(addr, size, 0,
+ IOMMU_RESV_RESERVED);
+ break;
+ }
+
+ list_add(&vdev->resv_regions, ®ion->list);
+
+ if (mem->subtype != VIRTIO_IOMMU_RESV_MEM_T_RESERVED &&
+ mem->subtype != VIRTIO_IOMMU_RESV_MEM_T_MSI) {
+ /* Please update your driver. */
+ pr_warn("unknown resv mem subtype 0x%x\n", mem->subtype);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int viommu_probe_endpoint(struct viommu_dev *viommu, struct device *dev)
+{
+ int ret;
+ u16 type, len;
+ size_t cur = 0;
+ struct virtio_iommu_req_probe *probe;
+ struct virtio_iommu_probe_property *prop;
+ struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+ struct viommu_endpoint *vdev = fwspec->iommu_priv;
+
+ if (!fwspec->num_ids)
+ /* Trouble ahead. */
+ return -EINVAL;
+
+ probe = kzalloc(sizeof(*probe) + viommu->probe_size +
+ sizeof(struct virtio_iommu_req_tail), GFP_KERNEL);
+ if (!probe)
+ return -ENOMEM;
+
+ probe->head.type = VIRTIO_IOMMU_T_PROBE;
+ /*
+ * For now, assume that properties of an endpoint that outputs multiple
+ * IDs are consistent. Only probe the first one.
+ */
+ probe->endpoint = cpu_to_le32(fwspec->ids[0]);
+
+ ret = viommu_send_req_sync(viommu, probe);
+ if (ret) {
+ kfree(probe);
+ return ret;
+ }
+
+ prop = (void *)probe->properties;
+ type = le16_to_cpu(prop->type) & VIRTIO_IOMMU_PROBE_T_MASK;
+
+ while (type != VIRTIO_IOMMU_PROBE_T_NONE &&
+ cur < viommu->probe_size) {
+ len = le16_to_cpu(prop->length);
+
+ switch (type) {
+ case VIRTIO_IOMMU_PROBE_T_RESV_MEM:
+ ret = viommu_add_resv_mem(vdev, (void *)prop->value, len);
+ break;
+ default:
+ dev_dbg(dev, "unknown viommu prop 0x%x\n", type);
+ }
+
+ if (ret)
+ dev_err(dev, "failed to parse viommu prop 0x%x\n", type);
+
+ cur += sizeof(*prop) + len;
+ if (cur >= viommu->probe_size)
+ break;
+
+ prop = (void *)probe->properties + cur;
+ type = le16_to_cpu(prop->type) & VIRTIO_IOMMU_PROBE_T_MASK;
+ }
+
+ kfree(probe);
+
+ return 0;
+}
+
/* IOMMU API */
static bool viommu_capable(enum iommu_cap cap)
@@ -706,6 +812,7 @@ static struct viommu_dev *viommu_get_by_fwnode(struct fwnode_handle *fwnode)
static int viommu_add_device(struct device *dev)
{
+ int ret;
struct iommu_group *group;
struct viommu_endpoint *vdev;
struct viommu_dev *viommu = NULL;
@@ -723,8 +830,16 @@ static int viommu_add_device(struct device *dev)
return -ENOMEM;
vdev->viommu = viommu;
+ INIT_LIST_HEAD(&vdev->resv_regions);
fwspec->iommu_priv = vdev;
+ if (viommu->probe_size) {
+ /* Get additional information for this endpoint */
+ ret = viommu_probe_endpoint(viommu, dev);
+ if (ret)
+ return ret;
+ }
+
/*
* Last step creates a default domain and attaches to it. Everything
* must be ready.
@@ -738,7 +853,19 @@ static int viommu_add_device(struct device *dev)
static void viommu_remove_device(struct device *dev)
{
- kfree(dev->iommu_fwspec->iommu_priv);
+ struct viommu_endpoint *vdev;
+ struct iommu_resv_region *entry, *next;
+ struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+ if (!fwspec || fwspec->ops != &viommu_ops)
+ return;
+
+ vdev = fwspec->iommu_priv;
+
+ list_for_each_entry_safe(entry, next, &vdev->resv_regions, list)
+ kfree(entry);
+
+ kfree(vdev);
}
static struct iommu_group *viommu_device_group(struct device *dev)
@@ -756,15 +883,34 @@ static int viommu_of_xlate(struct device *dev, struct of_phandle_args *args)
static void viommu_get_resv_regions(struct device *dev, struct list_head *head)
{
- struct iommu_resv_region *region;
+ struct iommu_resv_region *entry, *new_entry, *msi = NULL;
+ struct viommu_endpoint *vdev = dev->iommu_fwspec->iommu_priv;
int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
- region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH, prot,
- IOMMU_RESV_SW_MSI);
- if (!region)
- return;
+ list_for_each_entry(entry, &vdev->resv_regions, list) {
+ /*
+ * If the device registered a bypass MSI windows, use it.
+ * Otherwise add a software-mapped region
+ */
+ if (entry->type == IOMMU_RESV_MSI)
+ msi = entry;
+
+ new_entry = kmemdup(entry, sizeof(*entry), GFP_KERNEL);
+ if (!new_entry)
+ return;
+ list_add_tail(&new_entry->list, head);
+ }
- list_add_tail(®ion->list, head);
+ if (!msi) {
+ msi = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
+ prot, IOMMU_RESV_SW_MSI);
+ if (!msi)
+ return;
+
+ list_add_tail(&msi->list, head);
+ }
+
+ iommu_dma_get_resv_regions(dev, head);
}
static void viommu_put_resv_regions(struct device *dev, struct list_head *head)
@@ -854,6 +1000,10 @@ static int viommu_probe(struct virtio_device *vdev)
struct virtio_iommu_config, domain_bits,
&viommu->domain_bits);
+ virtio_cread_feature(vdev, VIRTIO_IOMMU_F_PROBE,
+ struct virtio_iommu_config, probe_size,
+ &viommu->probe_size);
+
viommu->geometry = (struct iommu_domain_geometry) {
.aperture_start = input_start,
.aperture_end = input_end,
@@ -931,6 +1081,7 @@ static unsigned int features[] = {
VIRTIO_IOMMU_F_MAP_UNMAP,
VIRTIO_IOMMU_F_DOMAIN_BITS,
VIRTIO_IOMMU_F_INPUT_RANGE,
+ VIRTIO_IOMMU_F_PROBE,
};
static struct virtio_device_id id_table[] = {
diff --git a/include/uapi/linux/virtio_iommu.h b/include/uapi/linux/virtio_iommu.h
index 2b4cd2042897..eec90a2ab547 100644
--- a/include/uapi/linux/virtio_iommu.h
+++ b/include/uapi/linux/virtio_iommu.h
@@ -38,6 +38,7 @@
#define VIRTIO_IOMMU_F_DOMAIN_BITS 1
#define VIRTIO_IOMMU_F_MAP_UNMAP 2
#define VIRTIO_IOMMU_F_BYPASS 3
+#define VIRTIO_IOMMU_F_PROBE 4
struct virtio_iommu_config {
/* Supported page sizes */
@@ -49,6 +50,9 @@ struct virtio_iommu_config {
} input_range;
/* Max domain ID size */
__u8 domain_bits;
+ __u8 padding[3];
+ /* Probe buffer size */
+ __u32 probe_size;
} __packed;
/* Request types */
@@ -56,6 +60,7 @@ struct virtio_iommu_config {
#define VIRTIO_IOMMU_T_DETACH 0x02
#define VIRTIO_IOMMU_T_MAP 0x03
#define VIRTIO_IOMMU_T_UNMAP 0x04
+#define VIRTIO_IOMMU_T_PROBE 0x05
/* Status types */
#define VIRTIO_IOMMU_S_OK 0x00
@@ -128,6 +133,37 @@ struct virtio_iommu_req_unmap {
struct virtio_iommu_req_tail tail;
} __packed;
+#define VIRTIO_IOMMU_RESV_MEM_T_RESERVED 0
+#define VIRTIO_IOMMU_RESV_MEM_T_MSI 1
+
+struct virtio_iommu_probe_resv_mem {
+ __u8 subtype;
+ __u8 reserved[3];
+ __le64 addr;
+ __le64 size;
+} __packed;
+
+#define VIRTIO_IOMMU_PROBE_T_NONE 0
+#define VIRTIO_IOMMU_PROBE_T_RESV_MEM 1
+
+#define VIRTIO_IOMMU_PROBE_T_MASK 0xfff
+
+struct virtio_iommu_probe_property {
+ __le16 type;
+ __le16 length;
+ __u8 value[];
+} __packed;
+
+struct virtio_iommu_req_probe {
+ struct virtio_iommu_req_head head;
+ __le32 endpoint;
+ __u8 reserved[64];
+
+ __u8 properties[];
+
+ /* Tail follows the variable-length properties array (no padding) */
+} __packed;
+
union virtio_iommu_req {
struct virtio_iommu_req_head head;
@@ -135,6 +171,7 @@ union virtio_iommu_req {
struct virtio_iommu_req_detach detach;
struct virtio_iommu_req_map map;
struct virtio_iommu_req_unmap unmap;
+ struct virtio_iommu_req_probe probe;
};
#endif
--
2.14.3
^ permalink raw reply related
* [RFC PATCH v2 1/5] iommu: Add virtio-iommu driver
From: Jean-Philippe Brucker @ 2017-11-17 18:52 UTC (permalink / raw)
To: iommu, devel, linux-acpi, kvm, kvmarm, virtualization, virtio-dev
Cc: Jayachandran.Nair, lorenzo.pieralisi, ashok.raj, mst,
marc.zyngier, will.deacon, rjw, robert.moore, eric.auger,
lv.zheng, sudeep.holla, lenb, robin.murphy, joro, hanjun.guo
In-Reply-To: <20171117185211.32593-1-jean-philippe.brucker@arm.com>
The virtio IOMMU is a para-virtualized device, allowing to send IOMMU
requests such as map/unmap over virtio-mmio transport without emulating
page tables. This implementation handle ATTACH, DETACH, MAP and UNMAP
requests.
The bulk of the code is to create requests and send them through virtio.
Implementing the IOMMU API is fairly straightforward since the
virtio-iommu MAP/UNMAP interface is almost identical.
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
---
drivers/iommu/Kconfig | 11 +
drivers/iommu/Makefile | 1 +
drivers/iommu/virtio-iommu.c | 958 ++++++++++++++++++++++++++++++++++++++
include/uapi/linux/virtio_ids.h | 1 +
include/uapi/linux/virtio_iommu.h | 140 ++++++
5 files changed, 1111 insertions(+)
create mode 100644 drivers/iommu/virtio-iommu.c
create mode 100644 include/uapi/linux/virtio_iommu.h
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 17b212f56e6a..7271e59e8b23 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -403,4 +403,15 @@ config QCOM_IOMMU
help
Support for IOMMU on certain Qualcomm SoCs.
+config VIRTIO_IOMMU
+ bool "Virtio IOMMU driver"
+ depends on VIRTIO_MMIO
+ select IOMMU_API
+ select INTERVAL_TREE
+ select ARM_DMA_USE_IOMMU if ARM
+ help
+ Para-virtualised IOMMU driver with virtio.
+
+ Say Y here if you intend to run this kernel as a guest.
+
endif # IOMMU_SUPPORT
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index dca71fe1c885..432242f3a328 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
obj-$(CONFIG_FSL_PAMU) += fsl_pamu.o fsl_pamu_domain.o
obj-$(CONFIG_S390_IOMMU) += s390-iommu.o
obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
+obj-$(CONFIG_VIRTIO_IOMMU) += virtio-iommu.o
diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
new file mode 100644
index 000000000000..feb8c8925c3a
--- /dev/null
+++ b/drivers/iommu/virtio-iommu.c
@@ -0,0 +1,958 @@
+/*
+ * Virtio driver for the paravirtualized IOMMU
+ *
+ * Copyright (C) 2017 ARM Limited
+ * Author: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/amba/bus.h>
+#include <linux/delay.h>
+#include <linux/dma-iommu.h>
+#include <linux/freezer.h>
+#include <linux/interval_tree.h>
+#include <linux/iommu.h>
+#include <linux/module.h>
+#include <linux/of_iommu.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+#include <linux/virtio.h>
+#include <linux/virtio_config.h>
+#include <linux/virtio_ids.h>
+#include <linux/wait.h>
+
+#include <uapi/linux/virtio_iommu.h>
+
+#define MSI_IOVA_BASE 0x8000000
+#define MSI_IOVA_LENGTH 0x100000
+
+struct viommu_dev {
+ struct iommu_device iommu;
+ struct device *dev;
+ struct virtio_device *vdev;
+
+ struct ida domain_ids;
+
+ struct virtqueue *vq;
+ /* Serialize anything touching the request queue */
+ spinlock_t request_lock;
+
+ /* Device configuration */
+ struct iommu_domain_geometry geometry;
+ u64 pgsize_bitmap;
+ u8 domain_bits;
+};
+
+struct viommu_mapping {
+ phys_addr_t paddr;
+ struct interval_tree_node iova;
+ union {
+ struct virtio_iommu_req_map map;
+ struct virtio_iommu_req_unmap unmap;
+ } req;
+};
+
+struct viommu_domain {
+ struct iommu_domain domain;
+ struct viommu_dev *viommu;
+ struct mutex mutex;
+ unsigned int id;
+
+ spinlock_t mappings_lock;
+ struct rb_root_cached mappings;
+
+ /* Number of endpoints attached to this domain */
+ refcount_t endpoints;
+};
+
+struct viommu_endpoint {
+ struct viommu_dev *viommu;
+ struct viommu_domain *vdomain;
+};
+
+struct viommu_request {
+ struct scatterlist top;
+ struct scatterlist bottom;
+
+ int written;
+ struct list_head list;
+};
+
+#define to_viommu_domain(domain) container_of(domain, struct viommu_domain, domain)
+
+/* Virtio transport */
+
+static int viommu_status_to_errno(u8 status)
+{
+ switch (status) {
+ case VIRTIO_IOMMU_S_OK:
+ return 0;
+ case VIRTIO_IOMMU_S_UNSUPP:
+ return -ENOSYS;
+ case VIRTIO_IOMMU_S_INVAL:
+ return -EINVAL;
+ case VIRTIO_IOMMU_S_RANGE:
+ return -ERANGE;
+ case VIRTIO_IOMMU_S_NOENT:
+ return -ENOENT;
+ case VIRTIO_IOMMU_S_FAULT:
+ return -EFAULT;
+ case VIRTIO_IOMMU_S_IOERR:
+ case VIRTIO_IOMMU_S_DEVERR:
+ default:
+ return -EIO;
+ }
+}
+
+/*
+ * viommu_get_req_size - compute request size
+ *
+ * A virtio-iommu request is split into one device-read-only part (top) and one
+ * device-write-only part (bottom). Given a request, return the sizes of the two
+ * parts in @top and @bottom.
+ *
+ * Return 0 on success, or an error when the request seems invalid.
+ */
+static int viommu_get_req_size(struct viommu_dev *viommu,
+ struct virtio_iommu_req_head *req, size_t *top,
+ size_t *bottom)
+{
+ size_t size;
+ union virtio_iommu_req *r = (void *)req;
+
+ *bottom = sizeof(struct virtio_iommu_req_tail);
+
+ switch (req->type) {
+ case VIRTIO_IOMMU_T_ATTACH:
+ size = sizeof(r->attach);
+ break;
+ case VIRTIO_IOMMU_T_DETACH:
+ size = sizeof(r->detach);
+ break;
+ case VIRTIO_IOMMU_T_MAP:
+ size = sizeof(r->map);
+ break;
+ case VIRTIO_IOMMU_T_UNMAP:
+ size = sizeof(r->unmap);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ *top = size - *bottom;
+ return 0;
+}
+
+static int viommu_receive_resp(struct viommu_dev *viommu, int nr_sent,
+ struct list_head *sent)
+{
+
+ unsigned int len;
+ int nr_received = 0;
+ struct viommu_request *req, *pending;
+
+ pending = list_first_entry_or_null(sent, struct viommu_request, list);
+ if (WARN_ON(!pending))
+ return 0;
+
+ while ((req = virtqueue_get_buf(viommu->vq, &len)) != NULL) {
+ if (req != pending) {
+ dev_warn(viommu->dev, "discarding stale request\n");
+ continue;
+ }
+
+ pending->written = len;
+
+ if (++nr_received == nr_sent) {
+ WARN_ON(!list_is_last(&pending->list, sent));
+ break;
+ } else if (WARN_ON(list_is_last(&pending->list, sent))) {
+ break;
+ }
+
+ pending = list_next_entry(pending, list);
+ }
+
+ return nr_received;
+}
+
+/* Must be called with request_lock held */
+static int _viommu_send_reqs_sync(struct viommu_dev *viommu,
+ struct viommu_request *req, int nr,
+ int *nr_sent)
+{
+ int i, ret;
+ ktime_t timeout;
+ LIST_HEAD(pending);
+ int nr_received = 0;
+ struct scatterlist *sg[2];
+ /*
+ * Yes, 1s timeout. As a guest, we don't necessarily have a precise
+ * notion of time and this just prevents locking up a CPU if the device
+ * dies.
+ */
+ unsigned long timeout_ms = 1000;
+
+ *nr_sent = 0;
+
+ for (i = 0; i < nr; i++, req++) {
+ req->written = 0;
+
+ sg[0] = &req->top;
+ sg[1] = &req->bottom;
+
+ ret = virtqueue_add_sgs(viommu->vq, sg, 1, 1, req,
+ GFP_ATOMIC);
+ if (ret)
+ break;
+
+ list_add_tail(&req->list, &pending);
+ }
+
+ if (i && !virtqueue_kick(viommu->vq))
+ return -EPIPE;
+
+ timeout = ktime_add_ms(ktime_get(), timeout_ms * i);
+ while (nr_received < i && ktime_before(ktime_get(), timeout)) {
+ nr_received += viommu_receive_resp(viommu, i - nr_received,
+ &pending);
+ if (nr_received < i) {
+ /*
+ * FIXME: what's a good way to yield to host? A second
+ * virtqueue_kick won't have any effect since we haven't
+ * added any descriptor.
+ */
+ udelay(10);
+ }
+ }
+
+ if (nr_received != i)
+ ret = -ETIMEDOUT;
+
+ if (ret == -ENOSPC && nr_received)
+ /*
+ * We've freed some space since virtio told us that the ring is
+ * full, tell the caller to come back for more.
+ */
+ ret = -EAGAIN;
+
+ *nr_sent = nr_received;
+
+ return ret;
+}
+
+/*
+ * viommu_send_reqs_sync - add a batch of requests, kick the host and wait for
+ * them to return
+ *
+ * @req: array of requests
+ * @nr: array length
+ * @nr_sent: on return, contains the number of requests actually sent
+ *
+ * Return 0 on success, or an error if we failed to send some of the requests.
+ */
+static int viommu_send_reqs_sync(struct viommu_dev *viommu,
+ struct viommu_request *req, int nr,
+ int *nr_sent)
+{
+ int ret;
+ int sent = 0;
+ unsigned long flags;
+
+ *nr_sent = 0;
+ do {
+ spin_lock_irqsave(&viommu->request_lock, flags);
+ ret = _viommu_send_reqs_sync(viommu, req, nr, &sent);
+ spin_unlock_irqrestore(&viommu->request_lock, flags);
+
+ *nr_sent += sent;
+ req += sent;
+ nr -= sent;
+ } while (ret == -EAGAIN);
+
+ return ret;
+}
+
+/*
+ * viommu_send_req_sync - send one request and wait for reply
+ *
+ * @top: pointer to a virtio_iommu_req_* structure
+ *
+ * Returns 0 if the request was successful, or an error number otherwise. No
+ * distinction is done between transport and request errors.
+ */
+static int viommu_send_req_sync(struct viommu_dev *viommu, void *top)
+{
+ int ret;
+ int nr_sent;
+ void *bottom;
+ struct viommu_request req = {0};
+ size_t top_size, bottom_size;
+ struct virtio_iommu_req_tail *tail;
+ struct virtio_iommu_req_head *head = top;
+
+ ret = viommu_get_req_size(viommu, head, &top_size, &bottom_size);
+ if (ret)
+ return ret;
+
+ bottom = top + top_size;
+ tail = bottom + bottom_size - sizeof(*tail);
+
+ sg_init_one(&req.top, top, top_size);
+ sg_init_one(&req.bottom, bottom, bottom_size);
+
+ ret = viommu_send_reqs_sync(viommu, &req, 1, &nr_sent);
+ if (ret || !req.written || nr_sent != 1) {
+ dev_err(viommu->dev, "failed to send request\n");
+ return -EIO;
+ }
+
+ return viommu_status_to_errno(tail->status);
+}
+
+/*
+ * viommu_add_mapping - add a mapping to the internal tree
+ *
+ * On success, return the new mapping. Otherwise return NULL.
+ */
+static struct viommu_mapping *
+viommu_add_mapping(struct viommu_domain *vdomain, unsigned long iova,
+ phys_addr_t paddr, size_t size)
+{
+ unsigned long flags;
+ struct viommu_mapping *mapping;
+
+ mapping = kzalloc(sizeof(*mapping), GFP_ATOMIC);
+ if (!mapping)
+ return NULL;
+
+ mapping->paddr = paddr;
+ mapping->iova.start = iova;
+ mapping->iova.last = iova + size - 1;
+
+ spin_lock_irqsave(&vdomain->mappings_lock, flags);
+ interval_tree_insert(&mapping->iova, &vdomain->mappings);
+ spin_unlock_irqrestore(&vdomain->mappings_lock, flags);
+
+ return mapping;
+}
+
+/*
+ * viommu_del_mappings - remove mappings from the internal tree
+ *
+ * @vdomain: the domain
+ * @iova: start of the range
+ * @size: size of the range. A size of 0 corresponds to the entire address
+ * space.
+ * @out_mapping: if not NULL, the first removed mapping is returned in there.
+ * This allows the caller to reuse the buffer for the unmap request. Caller
+ * must always free the returned mapping, whether the function succeeds or
+ * not.
+ *
+ * On success, returns the number of unmapped bytes (>= size)
+ */
+static size_t viommu_del_mappings(struct viommu_domain *vdomain,
+ unsigned long iova, size_t size,
+ struct viommu_mapping **out_mapping)
+{
+ size_t unmapped = 0;
+ unsigned long flags;
+ unsigned long last = iova + size - 1;
+ struct viommu_mapping *mapping = NULL;
+ struct interval_tree_node *node, *next;
+
+ spin_lock_irqsave(&vdomain->mappings_lock, flags);
+ next = interval_tree_iter_first(&vdomain->mappings, iova, last);
+
+ if (next) {
+ mapping = container_of(next, struct viommu_mapping, iova);
+ /* Trying to split a mapping? */
+ if (WARN_ON(mapping->iova.start < iova))
+ next = NULL;
+ }
+
+ while (next) {
+ node = next;
+ mapping = container_of(node, struct viommu_mapping, iova);
+
+ next = interval_tree_iter_next(node, iova, last);
+
+ /*
+ * Note that for a partial range, this will return the full
+ * mapping so we avoid sending split requests to the device.
+ */
+ unmapped += mapping->iova.last - mapping->iova.start + 1;
+
+ interval_tree_remove(node, &vdomain->mappings);
+
+ if (out_mapping && !(*out_mapping))
+ *out_mapping = mapping;
+ else
+ kfree(mapping);
+ }
+ spin_unlock_irqrestore(&vdomain->mappings_lock, flags);
+
+ return unmapped;
+}
+
+/*
+ * viommu_replay_mappings - re-send MAP requests
+ *
+ * When reattaching a domain that was previously detached from all devices,
+ * mappings were deleted from the device. Re-create the mappings available in
+ * the internal tree.
+ *
+ * Caller should hold the mapping lock if necessary.
+ */
+static int viommu_replay_mappings(struct viommu_domain *vdomain)
+{
+ int i = 1, ret, nr_sent;
+ struct viommu_request *reqs;
+ struct viommu_mapping *mapping;
+ struct interval_tree_node *node;
+ size_t top_size, bottom_size;
+
+ node = interval_tree_iter_first(&vdomain->mappings, 0, -1UL);
+ if (!node)
+ return 0;
+
+ while ((node = interval_tree_iter_next(node, 0, -1UL)) != NULL)
+ i++;
+
+ reqs = kcalloc(i, sizeof(*reqs), GFP_KERNEL);
+ if (!reqs)
+ return -ENOMEM;
+
+ bottom_size = sizeof(struct virtio_iommu_req_tail);
+ top_size = sizeof(struct virtio_iommu_req_map) - bottom_size;
+
+ i = 0;
+ node = interval_tree_iter_first(&vdomain->mappings, 0, -1UL);
+ while (node) {
+ mapping = container_of(node, struct viommu_mapping, iova);
+ sg_init_one(&reqs[i].top, &mapping->req.map, top_size);
+ sg_init_one(&reqs[i].bottom, &mapping->req.map.tail,
+ bottom_size);
+
+ node = interval_tree_iter_next(node, 0, -1UL);
+ i++;
+ }
+
+ ret = viommu_send_reqs_sync(vdomain->viommu, reqs, i, &nr_sent);
+ kfree(reqs);
+
+ return ret;
+}
+
+/* IOMMU API */
+
+static bool viommu_capable(enum iommu_cap cap)
+{
+ return false; /* :( */
+}
+
+static struct iommu_domain *viommu_domain_alloc(unsigned type)
+{
+ struct viommu_domain *vdomain;
+
+ if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA)
+ return NULL;
+
+ vdomain = kzalloc(sizeof(*vdomain), GFP_KERNEL);
+ if (!vdomain)
+ return NULL;
+
+ mutex_init(&vdomain->mutex);
+ spin_lock_init(&vdomain->mappings_lock);
+ vdomain->mappings = RB_ROOT_CACHED;
+ refcount_set(&vdomain->endpoints, 0);
+
+ if (type == IOMMU_DOMAIN_DMA &&
+ iommu_get_dma_cookie(&vdomain->domain)) {
+ kfree(vdomain);
+ return NULL;
+ }
+
+ return &vdomain->domain;
+}
+
+static int viommu_domain_finalise(struct viommu_dev *viommu,
+ struct iommu_domain *domain)
+{
+ int ret;
+ struct viommu_domain *vdomain = to_viommu_domain(domain);
+ /* ida limits size to 31 bits. A value of 0 means "max" */
+ unsigned int max_domain = viommu->domain_bits >= 31 ? 0 :
+ 1U << viommu->domain_bits;
+
+ vdomain->viommu = viommu;
+
+ domain->pgsize_bitmap = viommu->pgsize_bitmap;
+ domain->geometry = viommu->geometry;
+
+ ret = ida_simple_get(&viommu->domain_ids, 0, max_domain, GFP_KERNEL);
+ if (ret >= 0)
+ vdomain->id = (unsigned int)ret;
+
+ return ret > 0 ? 0 : ret;
+}
+
+static void viommu_domain_free(struct iommu_domain *domain)
+{
+ struct viommu_domain *vdomain = to_viommu_domain(domain);
+
+ iommu_put_dma_cookie(domain);
+
+ /* Free all remaining mappings (size 2^64) */
+ viommu_del_mappings(vdomain, 0, 0, NULL);
+
+ if (vdomain->viommu)
+ ida_simple_remove(&vdomain->viommu->domain_ids, vdomain->id);
+
+ kfree(vdomain);
+}
+
+static int viommu_attach_dev(struct iommu_domain *domain, struct device *dev)
+{
+ int i;
+ int ret = 0;
+ struct virtio_iommu_req_attach *req;
+ struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+ struct viommu_endpoint *vdev = fwspec->iommu_priv;
+ struct viommu_domain *vdomain = to_viommu_domain(domain);
+
+ mutex_lock(&vdomain->mutex);
+ if (!vdomain->viommu) {
+ /*
+ * Initialize the domain proper now that we know which viommu
+ * owns it.
+ */
+ ret = viommu_domain_finalise(vdev->viommu, domain);
+ } else if (vdomain->viommu != vdev->viommu) {
+ dev_err(dev, "cannot attach to foreign vIOMMU\n");
+ ret = -EXDEV;
+ }
+ mutex_unlock(&vdomain->mutex);
+
+ if (ret)
+ return ret;
+
+ /*
+ * When attaching the device to a new domain, it will be detached from
+ * the old one and, if as as a result the old domain isn't attached to
+ * any device, all mappings are removed from the old domain and it is
+ * freed. (Note that we can't use get_domain_for_dev here, it returns
+ * the default domain during initial attach.)
+ *
+ * Take note of the device disappearing, so we can ignore unmap request
+ * on stale domains (that is, between this detach and the upcoming
+ * free.)
+ *
+ * vdev->vdomain is protected by group->mutex
+ */
+ if (vdev->vdomain)
+ refcount_dec(&vdev->vdomain->endpoints);
+
+ /* DMA to the stack is forbidden, store request on the heap */
+ req = kzalloc(sizeof(*req), GFP_KERNEL);
+ if (!req)
+ return -ENOMEM;
+
+ *req = (struct virtio_iommu_req_attach) {
+ .head.type = VIRTIO_IOMMU_T_ATTACH,
+ .domain = cpu_to_le32(vdomain->id),
+ };
+
+ for (i = 0; i < fwspec->num_ids; i++) {
+ req->endpoint = cpu_to_le32(fwspec->ids[i]);
+
+ ret = viommu_send_req_sync(vdomain->viommu, req);
+ if (ret)
+ break;
+ }
+
+ kfree(req);
+
+ if (ret)
+ return ret;
+
+ if (!refcount_read(&vdomain->endpoints)) {
+ /*
+ * This endpoint is the first to be attached to the domain.
+ * Replay existing mappings if any.
+ */
+ ret = viommu_replay_mappings(vdomain);
+ if (ret)
+ return ret;
+ }
+
+ refcount_inc(&vdomain->endpoints);
+ vdev->vdomain = vdomain;
+
+ return 0;
+}
+
+static int viommu_map(struct iommu_domain *domain, unsigned long iova,
+ phys_addr_t paddr, size_t size, int prot)
+{
+ int ret;
+ int flags;
+ struct viommu_mapping *mapping;
+ struct viommu_domain *vdomain = to_viommu_domain(domain);
+
+ mapping = viommu_add_mapping(vdomain, iova, paddr, size);
+ if (!mapping)
+ return -ENOMEM;
+
+ flags = (prot & IOMMU_READ ? VIRTIO_IOMMU_MAP_F_READ : 0) |
+ (prot & IOMMU_WRITE ? VIRTIO_IOMMU_MAP_F_WRITE : 0);
+
+ mapping->req.map = (struct virtio_iommu_req_map) {
+ .head.type = VIRTIO_IOMMU_T_MAP,
+ .domain = cpu_to_le32(vdomain->id),
+ .virt_addr = cpu_to_le64(iova),
+ .phys_addr = cpu_to_le64(paddr),
+ .size = cpu_to_le64(size),
+ .flags = cpu_to_le32(flags),
+ };
+
+ if (!refcount_read(&vdomain->endpoints))
+ return 0;
+
+ ret = viommu_send_req_sync(vdomain->viommu, &mapping->req);
+ if (ret)
+ viommu_del_mappings(vdomain, iova, size, NULL);
+
+ return ret;
+}
+
+static size_t viommu_unmap(struct iommu_domain *domain, unsigned long iova,
+ size_t size)
+{
+ int ret = 0;
+ size_t unmapped;
+ struct viommu_mapping *mapping = NULL;
+ struct viommu_domain *vdomain = to_viommu_domain(domain);
+
+ unmapped = viommu_del_mappings(vdomain, iova, size, &mapping);
+ if (unmapped < size) {
+ ret = -EINVAL;
+ goto out_free;
+ }
+
+ /* Device already removed all mappings after detach. */
+ if (!refcount_read(&vdomain->endpoints))
+ goto out_free;
+
+ if (WARN_ON(!mapping))
+ return 0;
+
+ mapping->req.unmap = (struct virtio_iommu_req_unmap) {
+ .head.type = VIRTIO_IOMMU_T_UNMAP,
+ .domain = cpu_to_le32(vdomain->id),
+ .virt_addr = cpu_to_le64(iova),
+ .size = cpu_to_le64(unmapped),
+ };
+
+ ret = viommu_send_req_sync(vdomain->viommu, &mapping->req);
+
+out_free:
+ if (mapping)
+ kfree(mapping);
+
+ return ret ? 0 : unmapped;
+}
+
+static phys_addr_t viommu_iova_to_phys(struct iommu_domain *domain,
+ dma_addr_t iova)
+{
+ u64 paddr = 0;
+ unsigned long flags;
+ struct viommu_mapping *mapping;
+ struct interval_tree_node *node;
+ struct viommu_domain *vdomain = to_viommu_domain(domain);
+
+ spin_lock_irqsave(&vdomain->mappings_lock, flags);
+ node = interval_tree_iter_first(&vdomain->mappings, iova, iova);
+ if (node) {
+ mapping = container_of(node, struct viommu_mapping, iova);
+ paddr = mapping->paddr + (iova - mapping->iova.start);
+ }
+ spin_unlock_irqrestore(&vdomain->mappings_lock, flags);
+
+ return paddr;
+}
+
+static struct iommu_ops viommu_ops;
+static struct virtio_driver virtio_iommu_drv;
+
+static int viommu_match_node(struct device *dev, void *data)
+{
+ return dev->parent->fwnode == data;
+}
+
+static struct viommu_dev *viommu_get_by_fwnode(struct fwnode_handle *fwnode)
+{
+ struct device *dev = driver_find_device(&virtio_iommu_drv.driver, NULL,
+ fwnode, viommu_match_node);
+ put_device(dev);
+
+ return dev ? dev_to_virtio(dev)->priv : NULL;
+}
+
+static int viommu_add_device(struct device *dev)
+{
+ struct iommu_group *group;
+ struct viommu_endpoint *vdev;
+ struct viommu_dev *viommu = NULL;
+ struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+
+ if (!fwspec || fwspec->ops != &viommu_ops)
+ return -ENODEV;
+
+ viommu = viommu_get_by_fwnode(fwspec->iommu_fwnode);
+ if (!viommu)
+ return -ENODEV;
+
+ vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
+ if (!vdev)
+ return -ENOMEM;
+
+ vdev->viommu = viommu;
+ fwspec->iommu_priv = vdev;
+
+ /*
+ * Last step creates a default domain and attaches to it. Everything
+ * must be ready.
+ */
+ group = iommu_group_get_for_dev(dev);
+ if (!IS_ERR(group))
+ iommu_group_put(group);
+
+ return PTR_ERR_OR_ZERO(group);
+}
+
+static void viommu_remove_device(struct device *dev)
+{
+ kfree(dev->iommu_fwspec->iommu_priv);
+}
+
+static struct iommu_group *viommu_device_group(struct device *dev)
+{
+ if (dev_is_pci(dev))
+ return pci_device_group(dev);
+ else
+ return generic_device_group(dev);
+}
+
+static int viommu_of_xlate(struct device *dev, struct of_phandle_args *args)
+{
+ return iommu_fwspec_add_ids(dev, args->args, 1);
+}
+
+static void viommu_get_resv_regions(struct device *dev, struct list_head *head)
+{
+ struct iommu_resv_region *region;
+ int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+
+ region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH, prot,
+ IOMMU_RESV_SW_MSI);
+ if (!region)
+ return;
+
+ list_add_tail(®ion->list, head);
+}
+
+static void viommu_put_resv_regions(struct device *dev, struct list_head *head)
+{
+ struct iommu_resv_region *entry, *next;
+
+ list_for_each_entry_safe(entry, next, head, list)
+ kfree(entry);
+}
+
+static struct iommu_ops viommu_ops = {
+ .capable = viommu_capable,
+ .domain_alloc = viommu_domain_alloc,
+ .domain_free = viommu_domain_free,
+ .attach_dev = viommu_attach_dev,
+ .map = viommu_map,
+ .unmap = viommu_unmap,
+ .map_sg = default_iommu_map_sg,
+ .iova_to_phys = viommu_iova_to_phys,
+ .add_device = viommu_add_device,
+ .remove_device = viommu_remove_device,
+ .device_group = viommu_device_group,
+ .of_xlate = viommu_of_xlate,
+ .get_resv_regions = viommu_get_resv_regions,
+ .put_resv_regions = viommu_put_resv_regions,
+};
+
+static int viommu_init_vq(struct viommu_dev *viommu)
+{
+ struct virtio_device *vdev = dev_to_virtio(viommu->dev);
+ const char *name = "request";
+ void *ret;
+
+ ret = virtio_find_single_vq(vdev, NULL, name);
+ if (IS_ERR(ret)) {
+ dev_err(viommu->dev, "cannot find VQ\n");
+ return PTR_ERR(ret);
+ }
+
+ viommu->vq = ret;
+
+ return 0;
+}
+
+static int viommu_probe(struct virtio_device *vdev)
+{
+ struct device *parent_dev = vdev->dev.parent;
+ struct viommu_dev *viommu = NULL;
+ struct device *dev = &vdev->dev;
+ u64 input_start = 0;
+ u64 input_end = -1UL;
+ int ret;
+
+ viommu = kzalloc(sizeof(*viommu), GFP_KERNEL);
+ if (!viommu)
+ return -ENOMEM;
+
+ spin_lock_init(&viommu->request_lock);
+ ida_init(&viommu->domain_ids);
+ viommu->dev = dev;
+ viommu->vdev = vdev;
+
+ ret = viommu_init_vq(viommu);
+ if (ret)
+ goto err_free_viommu;
+
+ virtio_cread(vdev, struct virtio_iommu_config, page_size_mask,
+ &viommu->pgsize_bitmap);
+
+ if (!viommu->pgsize_bitmap) {
+ ret = -EINVAL;
+ goto err_free_viommu;
+ }
+
+ viommu->domain_bits = 32;
+
+ /* Optional features */
+ virtio_cread_feature(vdev, VIRTIO_IOMMU_F_INPUT_RANGE,
+ struct virtio_iommu_config, input_range.start,
+ &input_start);
+
+ virtio_cread_feature(vdev, VIRTIO_IOMMU_F_INPUT_RANGE,
+ struct virtio_iommu_config, input_range.end,
+ &input_end);
+
+ virtio_cread_feature(vdev, VIRTIO_IOMMU_F_DOMAIN_BITS,
+ struct virtio_iommu_config, domain_bits,
+ &viommu->domain_bits);
+
+ viommu->geometry = (struct iommu_domain_geometry) {
+ .aperture_start = input_start,
+ .aperture_end = input_end,
+ .force_aperture = true,
+ };
+
+ viommu_ops.pgsize_bitmap = viommu->pgsize_bitmap;
+
+ virtio_device_ready(vdev);
+
+ ret = iommu_device_sysfs_add(&viommu->iommu, dev, NULL, "%s",
+ virtio_bus_name(vdev));
+ if (ret)
+ goto err_free_viommu;
+
+ iommu_device_set_ops(&viommu->iommu, &viommu_ops);
+ iommu_device_set_fwnode(&viommu->iommu, parent_dev->fwnode);
+
+ iommu_device_register(&viommu->iommu);
+
+#ifdef CONFIG_PCI
+ if (pci_bus_type.iommu_ops != &viommu_ops) {
+ pci_request_acs();
+ ret = bus_set_iommu(&pci_bus_type, &viommu_ops);
+ if (ret)
+ goto err_unregister;
+ }
+#endif
+#ifdef CONFIG_ARM_AMBA
+ if (amba_bustype.iommu_ops != &viommu_ops) {
+ ret = bus_set_iommu(&amba_bustype, &viommu_ops);
+ if (ret)
+ goto err_unregister;
+ }
+#endif
+ if (platform_bus_type.iommu_ops != &viommu_ops) {
+ ret = bus_set_iommu(&platform_bus_type, &viommu_ops);
+ if (ret)
+ goto err_unregister;
+ }
+
+ vdev->priv = viommu;
+
+ dev_info(dev, "input address: %u bits\n",
+ order_base_2(viommu->geometry.aperture_end));
+ dev_info(dev, "page mask: %#llx\n", viommu->pgsize_bitmap);
+
+ return 0;
+
+err_unregister:
+ iommu_device_unregister(&viommu->iommu);
+
+err_free_viommu:
+ kfree(viommu);
+
+ return ret;
+}
+
+static void viommu_remove(struct virtio_device *vdev)
+{
+ struct viommu_dev *viommu = vdev->priv;
+
+ iommu_device_unregister(&viommu->iommu);
+ kfree(viommu);
+
+ dev_info(&vdev->dev, "device removed\n");
+}
+
+static void viommu_config_changed(struct virtio_device *vdev)
+{
+ dev_warn(&vdev->dev, "config changed\n");
+}
+
+static unsigned int features[] = {
+ VIRTIO_IOMMU_F_MAP_UNMAP,
+ VIRTIO_IOMMU_F_DOMAIN_BITS,
+ VIRTIO_IOMMU_F_INPUT_RANGE,
+};
+
+static struct virtio_device_id id_table[] = {
+ { VIRTIO_ID_IOMMU, VIRTIO_DEV_ANY_ID },
+ { 0 },
+};
+
+static struct virtio_driver virtio_iommu_drv = {
+ .driver.name = KBUILD_MODNAME,
+ .driver.owner = THIS_MODULE,
+ .id_table = id_table,
+ .feature_table = features,
+ .feature_table_size = ARRAY_SIZE(features),
+ .probe = viommu_probe,
+ .remove = viommu_remove,
+ .config_changed = viommu_config_changed,
+};
+
+module_virtio_driver(virtio_iommu_drv);
+
+IOMMU_OF_DECLARE(viommu, "virtio,mmio", NULL);
+
+MODULE_DESCRIPTION("Virtio IOMMU driver");
+MODULE_AUTHOR("Jean-Philippe Brucker <jean-philippe.brucker@arm.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/uapi/linux/virtio_ids.h b/include/uapi/linux/virtio_ids.h
index 6d5c3b2d4f4d..934ed3d3cd3f 100644
--- a/include/uapi/linux/virtio_ids.h
+++ b/include/uapi/linux/virtio_ids.h
@@ -43,5 +43,6 @@
#define VIRTIO_ID_INPUT 18 /* virtio input */
#define VIRTIO_ID_VSOCK 19 /* virtio vsock transport */
#define VIRTIO_ID_CRYPTO 20 /* virtio crypto */
+#define VIRTIO_ID_IOMMU 61216 /* virtio IOMMU (temporary) */
#endif /* _LINUX_VIRTIO_IDS_H */
diff --git a/include/uapi/linux/virtio_iommu.h b/include/uapi/linux/virtio_iommu.h
new file mode 100644
index 000000000000..2b4cd2042897
--- /dev/null
+++ b/include/uapi/linux/virtio_iommu.h
@@ -0,0 +1,140 @@
+/*
+ * Virtio-iommu definition v0.5
+ *
+ * Copyright (C) 2017 ARM Ltd.
+ *
+ * This header is BSD licensed so anyone can use the definitions
+ * to implement compatible drivers/servers:
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of ARM Ltd. nor the names of its contributors
+ * may be used to endorse or promote products derived from this software
+ * without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL IBM OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+ * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+#ifndef _UAPI_LINUX_VIRTIO_IOMMU_H
+#define _UAPI_LINUX_VIRTIO_IOMMU_H
+
+/* Feature bits */
+#define VIRTIO_IOMMU_F_INPUT_RANGE 0
+#define VIRTIO_IOMMU_F_DOMAIN_BITS 1
+#define VIRTIO_IOMMU_F_MAP_UNMAP 2
+#define VIRTIO_IOMMU_F_BYPASS 3
+
+struct virtio_iommu_config {
+ /* Supported page sizes */
+ __u64 page_size_mask;
+ /* Supported IOVA range */
+ struct virtio_iommu_range {
+ __u64 start;
+ __u64 end;
+ } input_range;
+ /* Max domain ID size */
+ __u8 domain_bits;
+} __packed;
+
+/* Request types */
+#define VIRTIO_IOMMU_T_ATTACH 0x01
+#define VIRTIO_IOMMU_T_DETACH 0x02
+#define VIRTIO_IOMMU_T_MAP 0x03
+#define VIRTIO_IOMMU_T_UNMAP 0x04
+
+/* Status types */
+#define VIRTIO_IOMMU_S_OK 0x00
+#define VIRTIO_IOMMU_S_IOERR 0x01
+#define VIRTIO_IOMMU_S_UNSUPP 0x02
+#define VIRTIO_IOMMU_S_DEVERR 0x03
+#define VIRTIO_IOMMU_S_INVAL 0x04
+#define VIRTIO_IOMMU_S_RANGE 0x05
+#define VIRTIO_IOMMU_S_NOENT 0x06
+#define VIRTIO_IOMMU_S_FAULT 0x07
+
+struct virtio_iommu_req_head {
+ __u8 type;
+ __u8 reserved[3];
+} __packed;
+
+struct virtio_iommu_req_tail {
+ __u8 status;
+ __u8 reserved[3];
+} __packed;
+
+struct virtio_iommu_req_attach {
+ struct virtio_iommu_req_head head;
+
+ __le32 domain;
+ __le32 endpoint;
+ __le32 reserved;
+
+ struct virtio_iommu_req_tail tail;
+} __packed;
+
+struct virtio_iommu_req_detach {
+ struct virtio_iommu_req_head head;
+
+ __le32 endpoint;
+ __le32 reserved;
+
+ struct virtio_iommu_req_tail tail;
+} __packed;
+
+#define VIRTIO_IOMMU_MAP_F_READ (1 << 0)
+#define VIRTIO_IOMMU_MAP_F_WRITE (1 << 1)
+#define VIRTIO_IOMMU_MAP_F_EXEC (1 << 2)
+
+#define VIRTIO_IOMMU_MAP_F_MASK (VIRTIO_IOMMU_MAP_F_READ | \
+ VIRTIO_IOMMU_MAP_F_WRITE | \
+ VIRTIO_IOMMU_MAP_F_EXEC)
+
+struct virtio_iommu_req_map {
+ struct virtio_iommu_req_head head;
+
+ __le32 domain;
+ __le64 virt_addr;
+ __le64 phys_addr;
+ __le64 size;
+ __le32 flags;
+
+ struct virtio_iommu_req_tail tail;
+} __packed;
+
+__packed
+struct virtio_iommu_req_unmap {
+ struct virtio_iommu_req_head head;
+
+ __le32 domain;
+ __le64 virt_addr;
+ __le64 size;
+ __le32 reserved;
+
+ struct virtio_iommu_req_tail tail;
+} __packed;
+
+union virtio_iommu_req {
+ struct virtio_iommu_req_head head;
+
+ struct virtio_iommu_req_attach attach;
+ struct virtio_iommu_req_detach detach;
+ struct virtio_iommu_req_map map;
+ struct virtio_iommu_req_unmap unmap;
+};
+
+#endif
--
2.14.3
^ permalink raw reply related
* [RFC PATCH v2 0/5] Add virtio-iommu driver
From: Jean-Philippe Brucker @ 2017-11-17 18:52 UTC (permalink / raw)
To: iommu, devel, linux-acpi, kvm, kvmarm, virtualization, virtio-dev
Cc: Jayachandran.Nair, lorenzo.pieralisi, ashok.raj, mst,
marc.zyngier, will.deacon, rjw, robert.moore, eric.auger,
lv.zheng, sudeep.holla, lenb, robin.murphy, joro, hanjun.guo
Implement the virtio-iommu driver following version 0.5 of the
specification [1]. Previous version of this code was sent back in April
[2], implementing the first public RFC. Since then there has been lots of
progress and discussion on the specification side, and I think the driver
is in a good shape now.
The reason patches 1-3 are only RFC is that I'm waiting on feedback from
the Virtio TC to reserve a device ID.
List of changes since previous RFC:
* Add per-endpoint probe request, for hardware MSI and reserved regions.
* Add a virtqueue for the device to report translation faults. Only
non-recoverable ones at the moment.
* Removed the iommu_map_sg specialization for now, because none of the
device drivers I use for testing (virtio, ixgbe and internal DMA
engines) seem to use map_sg. This kind of feature is a lot more
interesting when accompanied by benchmark numbers, and can be added back
during future optimization work.
* Many fixes and cleanup
The driver works out of the box on DT-based systems, but ACPI support
still needs to be tested and discussed. In the specification I proposed
IORT tables as a nice candidate for describing the virtual topology.
Patches 4 and 5 propose small changes to the IORT driver for
instantiating a paravirtualized IOMMU. The IORT node is described in the
specification [1]. x86 support will also require some hacks since the
driver is based on the IOMMU DMA ops, that x86 doesn't use.
Eric's latest QEMU device [3] works with v0.4. For the moment you can use
the kvmtool device [4] to test v0.5 on arm64, and inject arbitrary fault
with the debug tool. The driver can also be pulled from my Linux tree [5].
[1] https://www.spinics.net/lists/kvm/msg157402.html
[2] https://patchwork.kernel.org/patch/9670273/
[3] https://lists.gnu.org/archive/html/qemu-arm/2017-09/msg00413.html
[4] git://linux-arm.org/kvmtool-jpb.git virtio-iommu/base
[5] git://linux-arm.org/linux-jpb.git virtio-iommu/v0.5-dev
Jean-Philippe Brucker (5):
iommu: Add virtio-iommu driver
iommu/virtio-iommu: Add probe request
iommu/virtio-iommu: Add event queue
ACPI/IORT: Support paravirtualized IOMMU
ACPI/IORT: Move IORT to the ACPI folder
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/arm64/Kconfig | 3 -
drivers/acpi/arm64/Makefile | 1 -
drivers/acpi/{arm64 => }/iort.c | 95 ++-
drivers/iommu/Kconfig | 12 +
drivers/iommu/Makefile | 1 +
drivers/iommu/virtio-iommu.c | 1219 +++++++++++++++++++++++++++++++++++++
include/acpi/actbl2.h | 18 +-
include/uapi/linux/virtio_ids.h | 1 +
include/uapi/linux/virtio_iommu.h | 195 ++++++
11 files changed, 1537 insertions(+), 12 deletions(-)
rename drivers/acpi/{arm64 => }/iort.c (92%)
create mode 100644 drivers/iommu/virtio-iommu.c
create mode 100644 include/uapi/linux/virtio_iommu.h
--
2.14.3
^ permalink raw reply
* Re: [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros
From: Borislav Petkov @ 2017-11-17 18:07 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Juergen Gross, Rusty Russell, Mike Galbraith, xen-devel,
Peter Zijlstra, Jiri Slaby, Boris Ostrovsky, x86, linux-kernel,
Sasha Levin, Chris Wright, Thomas Gleixner, Andy Lutomirski,
H. Peter Anvin, live-patching, Alok Kataria, virtualization,
Linus Torvalds, Ingo Molnar
In-Reply-To: <e4cea2b8aa8ca23122d9c807784ca62ee6cbbff8.1507128293.git.jpoimboe@redhat.com>
On Wed, Oct 04, 2017 at 10:58:24AM -0500, Josh Poimboeuf wrote:
> Convert the hard-coded native patch assembly code strings to macros to
> facilitate sharing common code between 32-bit and 64-bit.
>
> These macros will also be used by a future patch which requires the GCC
> extended asm syntax of two '%' characters instead of one when specifying
> a register name.
>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> ---
> arch/x86/include/asm/special_insns.h | 24 ++++++++++++++++++++++++
> arch/x86/kernel/paravirt_patch_32.c | 21 +++++++++++----------
> arch/x86/kernel/paravirt_patch_64.c | 29 +++++++++++++++--------------
> 3 files changed, 50 insertions(+), 24 deletions(-)
>
> diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/special_insns.h
> index ac402c6fc24b..0549c5f2c1b3 100644
> --- a/arch/x86/include/asm/special_insns.h
> +++ b/arch/x86/include/asm/special_insns.h
> @@ -6,6 +6,30 @@
>
> #include <asm/nops.h>
>
> +#ifdef CONFIG_X86_64
> +# define _REG_ARG1 "%rdi"
> +# define NATIVE_IDENTITY_32 "mov %edi, %eax"
Yeah, that "identity" looks strange. How about NATIVE_NOOP and
NATIVE_NOOP_32 ?
> +# define NATIVE_USERGS_SYSRET64 "swapgs; sysretq"
> +#else
> +# define _REG_ARG1 "%eax"
> +#endif
> +
> +#define _REG_RET "%" _ASM_AX
> +
> +#define NATIVE_ZERO "xor " _REG_ARG1 ", " _REG_ARG1
NATIVE_ZERO_OUT
I guess. NATIVE_ZERO reads like the native representation of 0 :-)
...
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk
From: Christian Borntraeger @ 2017-11-17 14:42 UTC (permalink / raw)
To: Jens Axboe, Michael S. Tsirkin, Jason Wang, linux-block,
virtualization
Cc: Bart Van Assche
When doing cpu hotplug in a KVM guest with virtio blk I get warnings like
747.652408] ------------[ cut here ]------------
[ 747.652410] WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 __blk_mq_run_hw_queue+0xd4/0x100
[ 747.652410] Modules linked in: dm_multipath
[ 747.652412] CPU: 4 PID: 2895 Comm: kworker/4:1H Tainted: G W 4.14.0+ #191
[ 747.652412] Hardware name: IBM 2964 NC9 704 (KVM/Linux)
[ 747.652414] Workqueue: kblockd blk_mq_run_work_fn
[ 747.652414] task: 0000000060680000 task.stack: 000000005ea30000
[ 747.652415] Krnl PSW : 0704f00180000000 0000000000505864 (__blk_mq_run_hw_queue+0xd4/0x100)
[ 747.652417] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3
[ 747.652417] Krnl GPRS: 0000000000000010 00000000000000ff 000000005cbec400 0000000000000000
[ 747.652418] 0000000063709120 0000000000000000 0000000063709500 0000000059fa44b0
[ 747.652418] 0000000059fa4480 0000000000000000 000000006370f700 0000000063709100
[ 747.652419] 000000005cbec500 0000000000970948 000000005ea33d80 000000005ea33d48
[ 747.652423] Krnl Code: 0000000000505854: ebaff0a00004 lmg %r10,%r15,160(%r15)
000000000050585a: c0f4ffe690d3 brcl 15,1d7a00
#0000000000505860: a7f40001 brc 15,505862
>0000000000505864: 581003b0 l %r1,944
0000000000505868: c01b001fff00 nilf %r1,2096896
000000000050586e: a784ffdb brc 8,505824
0000000000505872: a7f40001 brc 15,505874
0000000000505876: 9120218f tm 399(%r2),32
[ 747.652435] Call Trace:
[ 747.652435] ([<0000000063709600>] 0x63709600)
[ 747.652436] [<0000000000187bcc>] process_one_work+0x264/0x4b8
[ 747.652438] [<0000000000187e78>] worker_thread+0x58/0x4f8
[ 747.652439] [<000000000018ee94>] kthread+0x144/0x168
[ 747.652439] [<00000000008f8a62>] kernel_thread_starter+0x6/0xc
[ 747.652440] [<00000000008f8a5c>] kernel_thread_starter+0x0/0xc
[ 747.652440] Last Breaking-Event-Address:
[ 747.652441] [<0000000000505860>] __blk_mq_run_hw_queue+0xd0/0x100
[ 747.652442] ---[ end trace 4a001a80379b18ba ]---
[ 747.652450] ------------[ cut here ]------------
This is
b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1141) * are mapped to it.
b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1142) */
6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1143) WARN_ON(!cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask) &&
6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1144) cpu_online(hctx->next_cpu));
6a83e74d2 (Bart Van Assche 2016-11-02 10:09:51 -0600 1145)
b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1146) /*
Is this a known issue?
Christian
^ permalink raw reply
* Re: [PATCH 01/13] x86/paravirt: remove wbinvd() paravirt interface
From: Borislav Petkov @ 2017-11-17 14:39 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Juergen Gross, Rusty Russell, Mike Galbraith, xen-devel,
Peter Zijlstra, Jiri Slaby, Boris Ostrovsky, x86, linux-kernel,
Sasha Levin, Chris Wright, Thomas Gleixner, Andy Lutomirski,
H. Peter Anvin, live-patching, Alok Kataria, virtualization,
Linus Torvalds, Ingo Molnar
In-Reply-To: <3f9bf17f6372ee92d984f6c7fd13e0cb14bc0e0a.1507128293.git.jpoimboe@redhat.com>
On Wed, Oct 04, 2017 at 10:58:22AM -0500, Josh Poimboeuf wrote:
> Since lguest was removed, only the native version of wbinvd() is used.
> The paravirt interface is no longer needed.
>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> ---
> arch/x86/include/asm/paravirt.h | 5 -----
> arch/x86/include/asm/paravirt_types.h | 1 -
> arch/x86/include/asm/special_insns.h | 7 +------
> arch/x86/kernel/paravirt.c | 1 -
> arch/x86/kernel/paravirt_patch_64.c | 2 --
> arch/x86/xen/enlighten_pv.c | 2 --
> 6 files changed, 1 insertion(+), 17 deletions(-)
Reviewed-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ 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