* Re: [v5] ath9k: Switch to using mac80211 intermediate software queues.
From: Tim Shepard @ 2016-11-09 2:44 UTC (permalink / raw)
To: Kalle Valo
Cc: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless,
Felix Fietkau
In-Reply-To: <1cd07522568b40a6a3e2db6170153c74@euamsexm01a.eu.qualcomm.com>
> While at it, could you also add to the commit log some info how awesome this
> patch is from user's point of view and how it helps. For example, before and
> and after numbers and other results.
That varies wildly, depending on many details of the scenario
(including the wireless capabilities of the clients connected to the
AP using this patch, and how far away those clients are). There's
really not enough room in a commit message to explain enough to make
any such claimed numbers reproducible.
And, BTW, this patch alone is not really where the big improvement
comes from. This just cuts ath9k over to use the new
transmit-a-packet interface between the mac80211 layer and the
wireless device driver. All the good work to improve latency is being
done on the new mac80211 interface to the driver to transmit a packet.
If you want numbers in a commit message, those numbers belong over on
those commits, not on this ath9k commit, IMHO.
And there's different patches that taken together achieve the best
improvement, and in various subsets differing amounts of improvement,
which again all depends on the scenarios.
And all this is complicated by how often real users are involved in
scenarios where this matters (hard to say).
This mainly improves things when you have an ath9k interface with
packets queued simultaneously to different wireless destinations,
which is typically when the ath9k interface is serving as an AP.
And I would expect similar improvements for any wireless driver cut
over to use the new mac80211 interface. (This patch might be a
helpful guide to other wireless driver maintainers wishing to see the
same improvements other wireless drivers.)
I hope that the above paragraphs were helpful.
-Tim Shepard
shep@alum.mit.edu
^ permalink raw reply
* Re: [PATCH v2 1/3] 99base: add memtrace-ko.sh to debug kernel module large memory consumption
From: Pratyush Anand @ 2016-11-09 3:06 UTC (permalink / raw)
To: xlpang-H+wXaHxf7aLQT0dZR+AlfA, Harald Hoyer, Dave Young
Cc: initramfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <58228E95.5090702-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Wednesday 09 November 2016 08:18 AM, Xunlei Pang wrote:
>> > Moreover, do we really need to trace module_put? You have filter for module loading applications, and pids for different module load instances would be different, so even if module_put is not tracked, it should work, no?
> We need to keep it, lets take an example to illustrate, "insmod mymodule" will hit "module_load" then "module_put"
> (even for insert failed cases), then other possible alloc_pages events, init function of the module is called between
> "module_load" and the following "module_put" trace point, we only care about alloc_pages events captured in between.
I do not have any strong feeling, so I am oK with what is there
currently implemented in this patch.
It was just to make it a bit more simple.
- We will have trace event generated only for the module insertion process.
- There would be a different PID for each insertion
- "The other possible alloc_pages events" described above would still
belong to same insmod operation (from userspace). And we will not have
any new page allocation until a new insmod or siblings start (so a new
PID). Therefore, why to set/unset.Just track with PID.
^ permalink raw reply
* [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
From: Dave Young @ 2016-11-09 3:01 UTC (permalink / raw)
To: wency, qiaonuohan; +Cc: lersek, anderson, qemu-devel, bhe
Hi,
Latest linux kernel enabled kaslr to randomiz phys/virt memory
addresses, we had some effort to support kexec/kdump so that crash
utility can still works in case crashed kernel has kaslr enabled.
But according to Dave Anderson virsh dump does not work, quoted messages
from Dave below:
"""
with virsh dump, there's no way of even knowing that KASLR
has randomized the kernel __START_KERNEL_map region, because there is no
virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump
vmcoreinfo data to compare against the vmlinux file symbol value.
Unless virsh dump can export some basic virtual memory data, which
they say it can't, I don't see how KASLR can ever be supported.
"""
I assume virsh dump is using qemu guest memory dump facility so it
should be first addressed in qemu. Thus post this query to qemu devel
list. If this is not correct please let me know.
Could you qemu dump people make it work? Or we can not support virt dump
as long as KASLR being enabled. Latest Fedora kernel has enabled it in x86_64.
Thanks
Dave
^ permalink raw reply
* 30577 linux-ide
From: beautyink @ 2016-11-09 3:00 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: MESSAGE_599190573_linux-ide.zip --]
[-- Type: application/zip, Size: 3124 bytes --]
^ permalink raw reply
* Re: [v3 4/5] vfio: implement APIs to set/put kvm to/from vfio group
From: Xiao Guangrong @ 2016-11-09 2:52 UTC (permalink / raw)
To: Jike Song, Alex Williamson
Cc: Paolo Bonzini, kwankhede, cjia, kevin.tian, kvm
In-Reply-To: <582289EA.9000101@intel.com>
On 11/09/2016 10:28 AM, Jike Song wrote:
> On 11/08/2016 02:28 AM, Alex Williamson wrote:
>> On Mon, 7 Nov 2016 19:10:37 +0100
>> Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> On 07/11/2016 19:04, Alex Williamson wrote:
>>>>>> +struct kvm *vfio_group_get_kvm(struct vfio_group *group)
>>>>>> +{
>>>>>> + struct kvm *kvm = NULL;
>>>> Unnecessary initialization.
>>>>
>>>>>> +
>>>>>> + mutex_lock(&group->udata.lock);
>>>>>> +
>>>>>> + kvm = group->udata.kvm;
>>>>>> + if (kvm)
>>>>>> + kvm_get_kvm(kvm);
>>>>>> +
>>>>>> + mutex_unlock(&group->udata.lock);
>>>>>> +
>>>>>> + return kvm;
>>>>>> +}
>>>>>> +EXPORT_SYMBOL_GPL(vfio_group_get_kvm);
>>>>
>>>> How are kvm references acquired through vfio_group_get_kvm() ever
>>>> released?
>>>
>>> They are released with kvm_put_kvm, but it's done in the vendor driver
>>> so that VFIO core doesn't have a dependency on kvm.ko.
>>
>> We could do a symbol_get() to avoid that so we could have a balanced
>> get/put through one interface.
>>
>>>> Can the reference become invalid?
>>>
>>> No, this is guaranteed by virt/kvm/vfio.c + the udata.lock mutex (which
>>> probably should be renamed...).
>>
>> The caller gets a reference to kvm, but there's no guarantee that the
>> association of that kvm reference to the group stays valid. Once we're
>> outside of that mutex, we might as well consider that kvm:group
>> association stale.
>>
>>>> The caller may still hold
>>>> a kvm references, but couldn't the group be detached from one kvm
>>>> instance and re-attached to another?
>>>
>>> Can this be handled by the vendor driver? Does it get a callback when
>>> it's detached from a KVM instance?
>>
>> The only release callback through vfio is when the user closes the
>> device, the code in this series is the full extent of vfio awareness of
>> kvm. Thanks,
>
> Hi Alex,
>
> Thanks for the comments, I'm composing a notifier chain in vfio-group,
> hopefully that can address current concerns.
>
> However, as for the vfio awareness of kvm, implementing notifiers doesn't
> seem better for that? Do you think if somehow, we are able to figure out
> a programmatic method in qemu, to trigger intel vGPU related quirks, would
> still be a better choice?
I do not think so,,, communicating VFIO with KVM should be generic as it may
have more users in the future except KVMGT.
I think notification is worth to try - vendor driver can register its
callbacks into vfio-group which get called when KVM binds/unbinds with VFIO
^ permalink raw reply
* Re: [PATCH v1 2/2] depmod: ignore related modules in depmod_report_cycles
From: Yauheni Kaliuta @ 2016-11-09 2:59 UTC (permalink / raw)
To: linux-modules; +Cc: Mian Yousaf Kaukab, bjorn.andersson, afaerber
In-Reply-To: <CAKi4VAKh0R-RN1j=Eum3wKtQ434D_7uBj1EGwzGCBrEB0qFkTg@mail.gmail.com>
Hi!
It may require more serious refactoring, since there is a problem with the
approach of path recording. I can get wrong output, for example, for the
following graph:
/*
mod6 -> mod7 -> mod8 -> mod9
^ | |
--------------- |
| |
-----------------------
*/
depmod: ERROR: Cycle detected: mod7 -> mod8 -> mod9 -> mod6 -> mod7
depmod: ERROR: Cycle detected: mod6 -> mod6
depmod: ERROR: Found 5 modules in dependency cycles!
The problem is that the path is recorded "globally", not per vertex, and
"wrong" mod6 is compared in "loop == m".
>>>>> On Tue, 8 Nov 2016 22:40:20 -0200, Lucas De Marchi wrote:
> On Tue, Nov 8, 2016 at 2:45 PM, Mian Yousaf Kaukab
> <yousaf.kaukab@suse.com> wrote:
>> Only print actual cyclic dependencies. Print count of all the modules
>> in cyclic dependency at the end of the function so that dependent
>> modules which are not in cyclic chain can be ignored.
>>
>> Printing dependent modules which are not in cyclic chain causes buffer
>> overflow as m->modnamesz is not included in buffer size calculations
>> (loop == m is never true). This buffer overflow causes kmod to crash.
>>
>> Update depmod test to reflect the change as well.
>>
>> Reported-by: Andreas Färber <afaerber@suse.de>
>> Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@suse.com>
>> ---
>> Change-log:
>> v1: Keep the old output stings. Only change their order
>> Add test case to reproduce the problem
>>
>> .../rootfs-pristine/test-depmod/detect-loop/correct.txt | 2 +-
>> tools/depmod.c | 13 ++++++++++++-
>> 2 files changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/testsuite/rootfs-pristine/test-depmod/detect-loop/correct.txt b/testsuite/rootfs-pristine/test-depmod/detect-loop/correct.txt
>> index 4eb26df..01ecb89 100644
>> --- a/testsuite/rootfs-pristine/test-depmod/detect-loop/correct.txt
>> +++ b/testsuite/rootfs-pristine/test-depmod/detect-loop/correct.txt
>> @@ -1,3 +1,3 @@
>> -depmod: ERROR: Found 5 modules in dependency cycles!
>> depmod: ERROR: Cycle detected: mod_loop_d -> mod_loop_e -> mod_loop_d
>> depmod: ERROR: Cycle detected: mod_loop_b -> mod_loop_c -> mod_loop_a -> mod_loop_b
>> +depmod: ERROR: Found 5 modules in dependency cycles!
>> diff --git a/tools/depmod.c b/tools/depmod.c
>> index ad01f66..f2b370f 100644
>> --- a/tools/depmod.c
>> +++ b/tools/depmod.c
>> @@ -1456,7 +1456,7 @@ static void depmod_report_cycles(struct depmod *depmod, uint16_t n_mods,
>> {
>> const char sep[] = " -> ";
>> int ir = 0;
>> - ERR("Found %u modules in dependency cycles!\n", n_roots);
>> + int num_cyclic = 0;
>>
>> while (n_roots > 0) {
>> int is, ie;
>> @@ -1491,6 +1491,7 @@ static void depmod_report_cycles(struct depmod *depmod, uint16_t n_mods,
>> if (m->visited) {
>> int i, n = 0, sz = 0;
>> char *buf;
>> + bool is_cyclic = false;
>>
>> for (i = ie - 1; i >= 0; i--) {
>> struct mod *loop = depmod->modules.array[edges[i]];
>> @@ -1498,9 +1499,17 @@ static void depmod_report_cycles(struct depmod *depmod, uint16_t n_mods,
>> n++;
>> if (loop == m) {
>> sz += loop->modnamesz - 1;
>> + is_cyclic = true;
>> break;
>> }
>> }
>> + /* Current module not found in dependency list.
>> + * Must be a related module. Ignore it.
>> + */
>> + if (!is_cyclic)
>> + continue;
>> +
>> + num_cyclic += n;
>>
>> buf = malloc(sz + n * strlen(sep) + 1);
>> sz = 0;
>> @@ -1538,6 +1547,8 @@ static void depmod_report_cycles(struct depmod *depmod, uint16_t n_mods,
>> }
>> }
>> }
>> +
>> + ERR("Found %d modules in dependency cycles!\n", num_cyclic);
>> }
> thanks, much better now.
> Applied.
--
WBR,
Yauheni Kaliuta
^ permalink raw reply
* linux-next: manual merge of the scsi-mkp tree with the scsi tree
From: Stephen Rothwell @ 2016-11-09 2:57 UTC (permalink / raw)
To: Martin K. Petersen, James Bottomley; +Cc: linux-next, linux-kernel
Hi Martin,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
drivers/scsi/ufs/ufs-qcom.c
Again this is caused by the rebase of the scsi-mkp tree (including
commits already in the scsi tree) followed by more changes to this file.
I fixed it up (I used the scsi-mkp tree version) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* 57913 linux-arch
From: jacqueline.pike @ 2016-11-09 2:55 UTC (permalink / raw)
To: linux-arch
[-- Attachment #1: MESSAGE_79813630137323_linux-arch.zip --]
[-- Type: application/zip, Size: 3653 bytes --]
^ permalink raw reply
* Re: [PATCH] kvmtool: README: kernel config to support virtio-blk devices
From: Xingyou Chen @ 2016-11-09 2:56 UTC (permalink / raw)
To: Will Deacon; +Cc: kvm
In-Reply-To: <20161108185539.GO20591@arm.com>
Kernel complains as:
VFS: Cannot open root device "vda" or unknown-
block(0,0): error -6
when configured with CONFIG_VIRTIO_BLK=y according
to README.
CONFIG_SCSI_VIRTIO=y is also needed to bring guest into disk
fs.
Signed-off-by: Xingyou Chen <niatlantice@gmail.com>
---
README | 1 +
1 file changed, 1 insertion(+)
diff --git a/README b/README
index 5501f05..a24b451 100644
--- a/README
+++ b/README
@@ -56,6 +56,7 @@ linux-0.2.img.bz2
- For virtio-blk devices (--disk, -d):
CONFIG_VIRTIO_BLK=y
+ CONFIG_SCSI_VIRTIO=y
- For virtio-net devices ([--network, -n] virtio):
CONFIG_VIRTIO_NET=y
--
2.10.2
^ permalink raw reply related
* Re: BUG: Hung task timeouts in for-4.10/dio
From: Damien Le Moal @ 2016-11-09 2:55 UTC (permalink / raw)
To: Jens Axboe, Christoph Hellwig; +Cc: Logan Gunthorpe, linux-block, Mike Snitzer
In-Reply-To: <f1a21c70-8161-7e2a-5945-5305637fde8e@kernel.dk>
Jens,
On 11/9/16 11:45, Jens Axboe wrote:
> I just committed the work-around. But yes, let's have a logical revert
> and require that REQ_SYNC be set for REQ_FUA|REQ_PREFLUSH to avoid it
> being this fragile.
Great ! Thank you.
-- =
Damien Le Moal, Ph.D.
Sr. Manager, System Software Research Group,
Western Digital Corporation
Damien.LeMoal@wdc.com
(+81) 0466-98-3593 (ext. 513593)
1 kirihara-cho, Fujisawa,
Kanagawa, 252-0888 Japan
www.wdc.com, www.hgst.com
Western Digital Corporation (and its subsidiaries) E-mail Confidentiality N=
otice & Disclaimer:
This e-mail and any files transmitted with it may contain confidential or l=
egally privileged information of WDC and/or its affiliates, and are intende=
d solely for the use of the individual or entity to which they are addresse=
d. If you are not the intended recipient, any disclosure, copying, distribu=
tion or any action taken or omitted to be taken in reliance on it, is prohi=
bited. If you have received this e-mail in error, please notify the sender =
immediately and delete the e-mail in its entirety from your system.
^ permalink raw reply
* linux-next: manual merge of the scsi-mkp tree with the block tree
From: Stephen Rothwell @ 2016-11-09 2:54 UTC (permalink / raw)
To: Martin K. Petersen, Jens Axboe
Cc: linux-next, linux-kernel, Christoph Hellwig
Hi Martin,
Today's linux-next merge of the scsi-mkp tree got conflicts in:
drivers/scsi/ufs/ufshcd.c
between commit:
e806402130c9 ("block: split out request-only flags into a new namespace")
from the block tree and commit:
dcea0bfbc4cb ("scsi: ufs: fix sense buffer size to 18 bytes")
from the scsi-mkp tree.
This latter commit also exists as commit 2266d5678ad1 in the scsi tree,
but unfortunately, the scsi-mkp tree was rebased overnight, so now the
two patches are not the same commit :-( A significant path of what was
rebased overnight has already been merged into the scsi tree ... so
please tidy up your tree WRT the scsi tree. This conflict would not
exist if the rebase had not been done.
I fixed it up (it is also fixed in the scsi tree merge and so just
taking that version of the resolution works) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging. You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: status of spdk
From: Dong Wu @ 2016-11-09 2:45 UTC (permalink / raw)
To: LIU, Fei; +Cc: Yehuda Sadeh-Weinraub, Sage Weil, Wang, Haomai, ceph-devel
In-Reply-To: <41F4566A-4573-4CB9-81F4-1688ED2534C1@alibaba-inc.com>
Hi, Yehuda and Haomai,
DPDK backend may have the same problem. I had tried to use
haomai's PR: https://github.com/ceph/ceph/pull/10748 to test dpdk
backend, but failed to start multiple OSDs on the host with only one
network card, alse i read about the dpdk multi-process support:
http://dpdk.org/doc/guides/prog_guide/multi_proc_support.html, but did
not find any config to set multi-process support. Anything wrong or
multi-process support not been implemented?
2016-11-09 8:21 GMT+08:00 LIU, Fei <james.liu@alibaba-inc.com>:
> Hi Yehuda and Haomai,
> The issue of drives driven by SPDK is not able to be shared by multiple OSDs as kernel NVMe drive since SPDK as a process so far can not be shared across multiple processes like OSDs, right?
>
> Regards,
> James
>
>
>
> On 11/8/16, 4:06 PM, "Yehuda Sadeh-Weinraub" <ceph-devel-owner@vger.kernel.org on behalf of yehuda@redhat.com> wrote:
>
> On Tue, Nov 8, 2016 at 3:40 PM, Sage Weil <sweil@redhat.com> wrote:
> > On Tue, 8 Nov 2016, Yehuda Sadeh-Weinraub wrote:
> >> I just started looking at spdk, and have a few comments and questions.
> >>
> >> First, it's not clear to me how we should handle build. At the moment
> >> the spdk code resides as a submodule in the ceph tree, but it depends
> >> on dpdk, which currently needs to be downloaded separately. We can add
> >> it as a submodule (upstream is here: git://dpdk.org/dpdk). That been
> >> said, getting it to build was a bit tricky and I think it might be
> >> broken with cmake. In order to get it working I resorted to building a
> >> system library and use that.
> >
> > Note that this PR is about to merge
> >
> > https://github.com/ceph/ceph/pull/10748
> >
> > which adds the DPDK submodule, so hopefully this issue will go away when
> > that merged or with a follow-on cleanup.
> >
> >> The way to currently configure an osd to use bluestore with spdk is by
> >> creating a symbolic link that replaces the bluestore 'block' device to
> >> point to a file that has a name that is prefixed with 'spdk:'.
> >> Originally I assumed that the suffix would be the nvme device id, but
> >> it seems that it's not really needed, however, the file itself needs
> >> to contain the device id (see
> >> https://github.com/yehudasa/ceph/tree/wip-yehuda-spdk for a couple of
> >> minor fixes).
> >
> > Open a PR for those?
>
> Sure
>
> >
> >> As I understand it, in order to support multiple osds on the same NVMe
> >> device we have a few options. We can leverage NVMe namespaces, but
> >> that's not supported on all devices. We can configure bluestore to
> >> only use part of the device (device sharding? not sure if it supports
> >> it). I think it's best if we could keep bluestore out of the loop
> >> there and have the NVMe driver abstract multiple partitions of the
> >> NVMe device. The idea is to be able to define multiple partitions on
> >> the device (e.g., each partition will be defined by the offset, size,
> >> and namespace), and have the osd set to use a specific partition.
> >> We'll probably need a special tool to manage it, and potentially keep
> >> the partition table information on the device itself. The tool could
> >> also manage the creation of the block link. We should probably rethink
> >> how the link is structure and what it points at.
> >
> > I agree that bluestore shouldn't get involved.
> >
> > Is the NVMe namespaces meant to support multiple processes sharing the
> > same hardware device?
>
> More of a partitioning solution, but yes (as far as I undestand).
>
> >
> > Also, if you do that, is it possible to give one of the namespaces to the
> > kernel? That might solve the bootstrapping problem we currently have
>
> Theoretically, but not right now (or ever?). See here:
>
> https://lists.01.org/pipermail/spdk/2016-July/000073.html
>
> > where we have nowhere to put the $osd_data filesystem with the device
> > metadata. (This is admittedly not necessarily a blocking issue. Putting
> > those dirs on / wouldn't be the end of the world; it just means cards
> > can't be easily moved between boxes.)
> >
>
> Maybe we can use bluestore for these too ;) that been said, there
> might be some kind of a loopback solution that could work, but not
> sure if it won't create major bottlenecks that we'd want to avoid.
>
> Yehuda
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: For playback method of stopping after the execution aplay command
From: 高井和也 @ 2016-11-09 2:52 UTC (permalink / raw)
To: Takashi Sakamoto; +Cc: alsa-devel
In-Reply-To: <12a7a95a-8405-d69f-611e-5944f6b59ca5@sakamocchi.jp>
Hi,
Thank you for your reply.
The inquiry sorry unclear.
After I was playing at aplay command, we are looking for a way to terminate
by the other process.
Regards
2016-11-09 11:47 GMT+09:00 Takashi Sakamoto <o-takashi@sakamocchi.jp>:
> Hi,
>
> On Nov 9 2016 10:36, 高井和也 wrote:
>
>> Hello
>>
>> Use ALSA aplay command we have developed a device for audio reproduction.
>>
>> After the audio playback at aplay command, forcibly or will not tell us
>> what should take what way to halt the play.
>> (After starting the aplay command, I tried a way to kill the process, but
>> it could have taken to stop playing, rarely Linux There was to be a
>> iowaitsleep state)
>>
>
> Do you look for a way to terminate aplay process by the other processes or
> a way to check a cause to terminate running aplay process?
>
>
> Regards
>
> Takashi Sakamoto
>
--
//--------------------------------------
// サン電子株式会社
// 技術開発部 開発２課
// 高井 和也
// 〒483-8555
// 愛知県江南市古知野町朝日250
// Tel:0587-55-2204, Fax:0587-53-8185
// E-Mail:ktakai@sun-denshi.co.jp
//--------------------------------------
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: Summary of LPC guest MSI discussion in Santa Fe
From: Don Dutile @ 2016-11-09 2:52 UTC (permalink / raw)
To: Alex Williamson, Christoffer Dall
Cc: Will Deacon, Eric Auger, eric.auger.pro, marc.zyngier,
robin.murphy, joro, tglx, jason, linux-arm-kernel, kvm, drjones,
linux-kernel, pranav.sawargaonkar, iommu, punit.agrawal,
diana.craciun, benh, arnd, jcm, dwmw
In-Reply-To: <20161108163508.1bcae0c2@t450s.home>
On 11/08/2016 06:35 PM, Alex Williamson wrote:
> On Tue, 8 Nov 2016 21:29:22 +0100
> Christoffer Dall <christoffer.dall@linaro.org> wrote:
>
>> Hi Will,
>>
>> On Tue, Nov 08, 2016 at 02:45:59AM +0000, Will Deacon wrote:
>>> Hi all,
>>>
>>> I figured this was a reasonable post to piggy-back on for the LPC minutes
>>> relating to guest MSIs on arm64.
>>>
>>> On Thu, Nov 03, 2016 at 10:02:05PM -0600, Alex Williamson wrote:
>>>> We can always have QEMU reject hot-adding the device if the reserved
>>>> region overlaps existing guest RAM, but I don't even really see how we
>>>> advise users to give them a reasonable chance of avoiding that
>>>> possibility. Apparently there are also ARM platforms where MSI pages
>>>> cannot be remapped to support the previous programmable user/VM
>>>> address, is it even worthwhile to support those platforms? Does that
>>>> decision influence whether user programmable MSI reserved regions are
>>>> really a second class citizen to fixed reserved regions? I expect
>>>> we'll be talking about this tomorrow morning, but I certainly haven't
>>>> come up with any viable solutions to this. Thanks,
>>>
>>> At LPC last week, we discussed guest MSIs on arm64 as part of the PCI
>>> microconference. I presented some slides to illustrate some of the issues
>>> we're trying to solve:
>>>
>>> http://www.willdeacon.ukfsn.org/bitbucket/lpc-16/msi-in-guest-arm64.pdf
>>>
>>> Punit took some notes (thanks!) on the etherpad here:
>>>
>>> https://etherpad.openstack.org/p/LPC2016_PCI
>>>
>>> although the discussion was pretty lively and jumped about, so I've had
>>> to go from memory where the notes didn't capture everything that was
>>> said.
>>>
>>> To summarise, arm64 platforms differ in their handling of MSIs when compared
>>> to x86:
>>>
>>> 1. The physical memory map is not standardised (Jon pointed out that
>>> this is something that was realised late on)
>>> 2. MSIs are usually treated the same as DMA writes, in that they must be
>>> mapped by the SMMU page tables so that they target a physical MSI
>>> doorbell
>>> 3. On some platforms, MSIs bypass the SMMU entirely (e.g. due to an MSI
>>> doorbell built into the PCI RC)
>>> 4. Platforms typically have some set of addresses that abort before
>>> reaching the SMMU (e.g. because the PCI identifies them as P2P).
>>>
>>> All of this means that userspace (QEMU) needs to identify the memory
>>> regions corresponding to points (3) and (4) and ensure that they are
>>> not allocated in the guest physical (IPA) space. For platforms that can
>>> remap the MSI doorbell as in (2), then some space also needs to be
>>> allocated for that.
>>>
>>> Rather than treat these as separate problems, a better interface is to
>>> tell userspace about a set of reserved regions, and have this include
>>> the MSI doorbell, irrespective of whether or not it can be remapped.
>>
>> Is my understanding correct, that you need to tell userspace about the
>> location of the doorbell (in the IOVA space) in case (2), because even
>> though the configuration of the device is handled by the (host) kernel
>> through trapping of the BARs, we have to avoid the VFIO user programming
>> the device to create other DMA transactions to this particular address,
>> since that will obviously conflict and either not produce the desired
>> DMA transactions or result in unintended weird interrupts?
>
> Correct, if the MSI doorbell IOVA range overlaps RAM in the VM, then
> it's potentially a DMA target and we'll get bogus data on DMA read from
> the device, and lose data and potentially trigger spurious interrupts on
> DMA write from the device. Thanks,
>
> Alex
>
That's b/c the MSI doorbells are not positioned *above* the SMMU, i.e.,
they address match before the SMMU checks are done. if
all DMA addrs had to go through SMMU first, then the DMA access could
be ignored/rejected.
For bare-metal, memory can't be put in the same place as MSI addrs, or
DMA could never reach it. So, only a virt issue, unless the VMs mem address
range mimic the host layout.
- Don
^ permalink raw reply
* Summary of LPC guest MSI discussion in Santa Fe
From: Don Dutile @ 2016-11-09 2:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108163508.1bcae0c2@t450s.home>
On 11/08/2016 06:35 PM, Alex Williamson wrote:
> On Tue, 8 Nov 2016 21:29:22 +0100
> Christoffer Dall <christoffer.dall@linaro.org> wrote:
>
>> Hi Will,
>>
>> On Tue, Nov 08, 2016 at 02:45:59AM +0000, Will Deacon wrote:
>>> Hi all,
>>>
>>> I figured this was a reasonable post to piggy-back on for the LPC minutes
>>> relating to guest MSIs on arm64.
>>>
>>> On Thu, Nov 03, 2016 at 10:02:05PM -0600, Alex Williamson wrote:
>>>> We can always have QEMU reject hot-adding the device if the reserved
>>>> region overlaps existing guest RAM, but I don't even really see how we
>>>> advise users to give them a reasonable chance of avoiding that
>>>> possibility. Apparently there are also ARM platforms where MSI pages
>>>> cannot be remapped to support the previous programmable user/VM
>>>> address, is it even worthwhile to support those platforms? Does that
>>>> decision influence whether user programmable MSI reserved regions are
>>>> really a second class citizen to fixed reserved regions? I expect
>>>> we'll be talking about this tomorrow morning, but I certainly haven't
>>>> come up with any viable solutions to this. Thanks,
>>>
>>> At LPC last week, we discussed guest MSIs on arm64 as part of the PCI
>>> microconference. I presented some slides to illustrate some of the issues
>>> we're trying to solve:
>>>
>>> http://www.willdeacon.ukfsn.org/bitbucket/lpc-16/msi-in-guest-arm64.pdf
>>>
>>> Punit took some notes (thanks!) on the etherpad here:
>>>
>>> https://etherpad.openstack.org/p/LPC2016_PCI
>>>
>>> although the discussion was pretty lively and jumped about, so I've had
>>> to go from memory where the notes didn't capture everything that was
>>> said.
>>>
>>> To summarise, arm64 platforms differ in their handling of MSIs when compared
>>> to x86:
>>>
>>> 1. The physical memory map is not standardised (Jon pointed out that
>>> this is something that was realised late on)
>>> 2. MSIs are usually treated the same as DMA writes, in that they must be
>>> mapped by the SMMU page tables so that they target a physical MSI
>>> doorbell
>>> 3. On some platforms, MSIs bypass the SMMU entirely (e.g. due to an MSI
>>> doorbell built into the PCI RC)
>>> 4. Platforms typically have some set of addresses that abort before
>>> reaching the SMMU (e.g. because the PCI identifies them as P2P).
>>>
>>> All of this means that userspace (QEMU) needs to identify the memory
>>> regions corresponding to points (3) and (4) and ensure that they are
>>> not allocated in the guest physical (IPA) space. For platforms that can
>>> remap the MSI doorbell as in (2), then some space also needs to be
>>> allocated for that.
>>>
>>> Rather than treat these as separate problems, a better interface is to
>>> tell userspace about a set of reserved regions, and have this include
>>> the MSI doorbell, irrespective of whether or not it can be remapped.
>>
>> Is my understanding correct, that you need to tell userspace about the
>> location of the doorbell (in the IOVA space) in case (2), because even
>> though the configuration of the device is handled by the (host) kernel
>> through trapping of the BARs, we have to avoid the VFIO user programming
>> the device to create other DMA transactions to this particular address,
>> since that will obviously conflict and either not produce the desired
>> DMA transactions or result in unintended weird interrupts?
>
> Correct, if the MSI doorbell IOVA range overlaps RAM in the VM, then
> it's potentially a DMA target and we'll get bogus data on DMA read from
> the device, and lose data and potentially trigger spurious interrupts on
> DMA write from the device. Thanks,
>
> Alex
>
That's b/c the MSI doorbells are not positioned *above* the SMMU, i.e.,
they address match before the SMMU checks are done. if
all DMA addrs had to go through SMMU first, then the DMA access could
be ignored/rejected.
For bare-metal, memory can't be put in the same place as MSI addrs, or
DMA could never reach it. So, only a virt issue, unless the VMs mem address
range mimic the host layout.
- Don
^ permalink raw reply
* Re: Summary of LPC guest MSI discussion in Santa Fe
From: Don Dutile @ 2016-11-09 2:52 UTC (permalink / raw)
To: Alex Williamson, Christoffer Dall
Cc: drjones-H+wXaHxf7aLQT0dZR+AlfA, jason-NLaQJdtUoK4Be96aLqz0jA,
kvm-u79uwXL29TY76Z2rM5mHXA, marc.zyngier-5wv7dgnIgG8,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, punit.agrawal-5wv7dgnIgG8,
Will Deacon, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
dwmw-vV1OtcyAfmbQXOPxS62xeg, jcm-H+wXaHxf7aLQT0dZR+AlfA,
tglx-hfZtesqFncYOwBW4kG4KsQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
eric.auger.pro-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20161108163508.1bcae0c2-1yVPhWWZRC1BDLzU/O5InQ@public.gmane.org>
On 11/08/2016 06:35 PM, Alex Williamson wrote:
> On Tue, 8 Nov 2016 21:29:22 +0100
> Christoffer Dall <christoffer.dall-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>
>> Hi Will,
>>
>> On Tue, Nov 08, 2016 at 02:45:59AM +0000, Will Deacon wrote:
>>> Hi all,
>>>
>>> I figured this was a reasonable post to piggy-back on for the LPC minutes
>>> relating to guest MSIs on arm64.
>>>
>>> On Thu, Nov 03, 2016 at 10:02:05PM -0600, Alex Williamson wrote:
>>>> We can always have QEMU reject hot-adding the device if the reserved
>>>> region overlaps existing guest RAM, but I don't even really see how we
>>>> advise users to give them a reasonable chance of avoiding that
>>>> possibility. Apparently there are also ARM platforms where MSI pages
>>>> cannot be remapped to support the previous programmable user/VM
>>>> address, is it even worthwhile to support those platforms? Does that
>>>> decision influence whether user programmable MSI reserved regions are
>>>> really a second class citizen to fixed reserved regions? I expect
>>>> we'll be talking about this tomorrow morning, but I certainly haven't
>>>> come up with any viable solutions to this. Thanks,
>>>
>>> At LPC last week, we discussed guest MSIs on arm64 as part of the PCI
>>> microconference. I presented some slides to illustrate some of the issues
>>> we're trying to solve:
>>>
>>> http://www.willdeacon.ukfsn.org/bitbucket/lpc-16/msi-in-guest-arm64.pdf
>>>
>>> Punit took some notes (thanks!) on the etherpad here:
>>>
>>> https://etherpad.openstack.org/p/LPC2016_PCI
>>>
>>> although the discussion was pretty lively and jumped about, so I've had
>>> to go from memory where the notes didn't capture everything that was
>>> said.
>>>
>>> To summarise, arm64 platforms differ in their handling of MSIs when compared
>>> to x86:
>>>
>>> 1. The physical memory map is not standardised (Jon pointed out that
>>> this is something that was realised late on)
>>> 2. MSIs are usually treated the same as DMA writes, in that they must be
>>> mapped by the SMMU page tables so that they target a physical MSI
>>> doorbell
>>> 3. On some platforms, MSIs bypass the SMMU entirely (e.g. due to an MSI
>>> doorbell built into the PCI RC)
>>> 4. Platforms typically have some set of addresses that abort before
>>> reaching the SMMU (e.g. because the PCI identifies them as P2P).
>>>
>>> All of this means that userspace (QEMU) needs to identify the memory
>>> regions corresponding to points (3) and (4) and ensure that they are
>>> not allocated in the guest physical (IPA) space. For platforms that can
>>> remap the MSI doorbell as in (2), then some space also needs to be
>>> allocated for that.
>>>
>>> Rather than treat these as separate problems, a better interface is to
>>> tell userspace about a set of reserved regions, and have this include
>>> the MSI doorbell, irrespective of whether or not it can be remapped.
>>
>> Is my understanding correct, that you need to tell userspace about the
>> location of the doorbell (in the IOVA space) in case (2), because even
>> though the configuration of the device is handled by the (host) kernel
>> through trapping of the BARs, we have to avoid the VFIO user programming
>> the device to create other DMA transactions to this particular address,
>> since that will obviously conflict and either not produce the desired
>> DMA transactions or result in unintended weird interrupts?
>
> Correct, if the MSI doorbell IOVA range overlaps RAM in the VM, then
> it's potentially a DMA target and we'll get bogus data on DMA read from
> the device, and lose data and potentially trigger spurious interrupts on
> DMA write from the device. Thanks,
>
> Alex
>
That's b/c the MSI doorbells are not positioned *above* the SMMU, i.e.,
they address match before the SMMU checks are done. if
all DMA addrs had to go through SMMU first, then the DMA access could
be ignored/rejected.
For bare-metal, memory can't be put in the same place as MSI addrs, or
DMA could never reach it. So, only a virt issue, unless the VMs mem address
range mimic the host layout.
- Don
^ permalink raw reply
* [PATCH] acpi: remove redundant declare of acpi_table_parse_entries
From: Longpeng(Mike) @ 2016-11-09 2:51 UTC (permalink / raw)
To: rjw, lenb
Cc: linux-acpi, linux-kernel, zhaoshenglong, wu.wubin, Longpeng(Mike)
This function declared twice, so remove one.
Signed-off-by: Longpeng(Mike) <longpeng2@huawei.com>
---
include/linux/acpi.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 689a8b9..017849e 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -220,10 +220,6 @@ int __init acpi_table_parse_entries(char *id, unsigned long table_size,
int entry_id,
acpi_tbl_entry_handler handler,
unsigned int max_entries);
-int __init acpi_table_parse_entries(char *id, unsigned long table_size,
- int entry_id,
- acpi_tbl_entry_handler handler,
- unsigned int max_entries);
int __init acpi_table_parse_entries_array(char *id, unsigned long table_size,
struct acpi_subtable_proc *proc, int proc_num,
unsigned int max_entries);
--
1.8.3.1
^ permalink raw reply related
* [PATCH] acpi: remove redundant declare of acpi_table_parse_entries
From: Longpeng(Mike) @ 2016-11-09 2:51 UTC (permalink / raw)
To: rjw, lenb
Cc: linux-acpi, linux-kernel, zhaoshenglong, wu.wubin, Longpeng(Mike)
This function declared twice, so remove one.
Signed-off-by: Longpeng(Mike) <longpeng2@huawei.com>
---
include/linux/acpi.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 689a8b9..017849e 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -220,10 +220,6 @@ int __init acpi_table_parse_entries(char *id, unsigned long table_size,
int entry_id,
acpi_tbl_entry_handler handler,
unsigned int max_entries);
-int __init acpi_table_parse_entries(char *id, unsigned long table_size,
- int entry_id,
- acpi_tbl_entry_handler handler,
- unsigned int max_entries);
int __init acpi_table_parse_entries_array(char *id, unsigned long table_size,
struct acpi_subtable_proc *proc, int proc_num,
unsigned int max_entries);
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/2] kdbus: Notifications and get_name_owner for unique names
From: Andrew Zaborowski @ 2016-11-09 2:51 UTC (permalink / raw)
To: ell
In-Reply-To: <1478659894-7142-1-git-send-email-andrew.zaborowski@intel.com>
[-- Attachment #1: Type: text/plain, Size: 3342 bytes --]
This is untested and may be of little value anyway.
---
ell/dbus-kernel.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 57 insertions(+), 2 deletions(-)
diff --git a/ell/dbus-kernel.c b/ell/dbus-kernel.c
index 2cd1d94..6544a87 100644
--- a/ell/dbus-kernel.c
+++ b/ell/dbus-kernel.c
@@ -596,6 +596,7 @@ int _dbus_kernel_recv(int fd, void *kdbus_pool,
int r;
size_t min_size;
const char *error;
+ char unique_bus_name[128];
memset(&recv_cmd, 0, sizeof(recv_cmd));
@@ -638,6 +639,27 @@ int _dbus_kernel_recv(int fd, void *kdbus_pool,
user_data);
break;
+ case KDBUS_ITEM_ID_ADD:
+ case KDBUS_ITEM_ID_REMOVE:
+ min_size = KDBUS_ITEM_SIZE(sizeof(item->id_change));
+ if (msg->size < sizeof(*msg) + min_size ||
+ item->size < min_size) {
+ r = -EPROTONOSUPPORT;
+ break;
+ }
+
+ sprintf(unique_bus_name, ":1.%llu", item->id_change.id);
+
+ if (item->type == KDBUS_ITEM_ID_ADD)
+ name_owner_change_func(unique_bus_name,
+ 0, item->id_change.id,
+ user_data);
+ else
+ name_owner_change_func(unique_bus_name,
+ item->id_change.id, 0,
+ user_data);
+ break;
+
case KDBUS_ITEM_REPLY_TIMEOUT:
case KDBUS_ITEM_REPLY_DEAD:
if (item->type == KDBUS_ITEM_REPLY_TIMEOUT)
@@ -828,7 +850,9 @@ int _dbus_kernel_enable_name_owner_notify(int fd)
struct {
struct kdbus_cmd_match cmd;
uint8_t param[KDBUS_ITEM_SIZE(
- sizeof(struct kdbus_notify_name_change))];
+ sizeof(struct kdbus_notify_name_change)) +
+ KDBUS_ITEM_SIZE(
+ sizeof(struct kdbus_notify_id_change))];
} cmd_match;
struct kdbus_item *item;
int r;
@@ -869,6 +893,28 @@ int _dbus_kernel_enable_name_owner_notify(int fd)
if (r < 0)
return -errno;
+ memset(&cmd_match, 0, sizeof(cmd_match));
+ item = cmd_match.cmd.items;
+ item->type = KDBUS_ITEM_ID_ADD;
+ item->size = KDBUS_ITEM_HEADER_SIZE + sizeof(item->id_change);
+ item->id_change.id = KDBUS_MATCH_ID_ANY;
+ cmd_match.cmd.size = sizeof(cmd_match.cmd) + item->size;
+
+ r = ioctl(fd, KDBUS_CMD_MATCH_ADD, &cmd_match);
+ if (r < 0)
+ return -errno;
+
+ memset(&cmd_match, 0, sizeof(cmd_match));
+ item = cmd_match.cmd.items;
+ item->type = KDBUS_ITEM_ID_REMOVE;
+ item->size = KDBUS_ITEM_HEADER_SIZE + sizeof(item->id_change);
+ item->id_change.id = KDBUS_MATCH_ID_ANY;
+ cmd_match.cmd.size = sizeof(cmd_match.cmd) + item->size;
+
+ r = ioctl(fd, KDBUS_CMD_MATCH_ADD, &cmd_match);
+ if (r < 0)
+ return -errno;
+
return 0;
}
@@ -881,10 +927,14 @@ uint64_t _dbus_kernel_get_name_owner(int fd, void *kdbus_pool,
struct kdbus_item *item;
const char *entry_name;
uint64_t owner_id = 0;
+ bool is_unique;
+ uint64_t uninitialized_var(id);
+
+ is_unique = _dbus_parse_unique_name(name, &id);
memset(&cmd, 0, sizeof(cmd));
cmd.size = sizeof(cmd);
- cmd.flags = KDBUS_LIST_NAMES;
+ cmd.flags = is_unique ? KDBUS_LIST_UNIQUE : KDBUS_LIST_NAMES;
if (ioctl(fd, KDBUS_CMD_LIST, &cmd) < 0)
return 0;
@@ -906,6 +956,11 @@ uint64_t _dbus_kernel_get_name_owner(int fd, void *kdbus_pool,
owner_id = entry->id;
break;
}
+
+ if (is_unique && id == entry->id) {
+ owner_id = id;
+ break;
+ }
}
memset(&cmd_free, 0, sizeof(cmd_free));
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] dbus: Fix disconnect watch with unique bus names
From: Andrew Zaborowski @ 2016-11-09 2:51 UTC (permalink / raw)
To: ell
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
Make the dbus-name-cache, service watches and disconnect watches work
with unique bus names. Problem spotted by Daniel Wagner and culprit
pointed out by Denis Kenzior.
---
ell/dbus-name-cache.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/ell/dbus-name-cache.c b/ell/dbus-name-cache.c
index 0c2e08e..cb6a516 100644
--- a/ell/dbus-name-cache.c
+++ b/ell/dbus-name-cache.c
@@ -178,9 +178,6 @@ void _dbus_name_cache_notify(struct _dbus_name_cache *cache,
if (!cache)
return;
- if (_dbus_parse_unique_name(name, NULL))
- return;
-
entry = l_hashmap_lookup(cache->names, name);
if (!entry)
--
2.7.4
^ permalink raw reply related
* [PATCH] arm/arm64: KVM: clean up useless code in kvm_timer_enable
From: Longpeng(Mike) @ 2016-11-09 2:50 UTC (permalink / raw)
To: christoffer.dall, marc.zyngier
Cc: pbonzini, rkrcmar, linux-arm-kernel, kvmarm, kvm, linux-kernel,
zhaoshenglong, wu.wubin, Longpeng(Mike)
1) Since commit:41a54482 changed timer enabled variable to per-vcpu,
the correlative comment in kvm_timer_enable is useless now.
2) After the kvm module init successfully, the timecounter is always
non-null, so we can remove the checking of timercounter.
Signed-off-by: Longpeng(Mike) <longpeng2@huawei.com>
---
virt/kvm/arm/arch_timer.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 27a1f63..17b8fa5 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -498,17 +498,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
if (ret)
return ret;
-
- /*
- * There is a potential race here between VCPUs starting for the first
- * time, which may be enabling the timer multiple times. That doesn't
- * hurt though, because we're just setting a variable to the same
- * variable that it already was. The important thing is that all
- * VCPUs have the enabled variable set, before entering the guest, if
- * the arch timers are enabled.
- */
- if (timecounter)
- timer->enabled = 1;
+ timer->enabled = 1;
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH] arm/arm64: KVM: clean up useless code in kvm_timer_enable
From: Longpeng(Mike) @ 2016-11-09 2:50 UTC (permalink / raw)
To: linux-arm-kernel
1) Since commit:41a54482 changed timer enabled variable to per-vcpu,
the correlative comment in kvm_timer_enable is useless now.
2) After the kvm module init successfully, the timecounter is always
non-null, so we can remove the checking of timercounter.
Signed-off-by: Longpeng(Mike) <longpeng2@huawei.com>
---
virt/kvm/arm/arch_timer.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 27a1f63..17b8fa5 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -498,17 +498,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
if (ret)
return ret;
-
- /*
- * There is a potential race here between VCPUs starting for the first
- * time, which may be enabling the timer multiple times. That doesn't
- * hurt though, because we're just setting a variable to the same
- * variable that it already was. The important thing is that all
- * VCPUs have the enabled variable set, before entering the guest, if
- * the arch timers are enabled.
- */
- if (timecounter)
- timer->enabled = 1;
+ timer->enabled = 1;
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH] arm/arm64: KVM: clean up useless code in kvm_timer_enable
From: Longpeng(Mike) @ 2016-11-09 2:50 UTC (permalink / raw)
To: christoffer.dall, marc.zyngier
Cc: pbonzini, rkrcmar, linux-arm-kernel, kvmarm, kvm, linux-kernel,
zhaoshenglong, wu.wubin, Longpeng(Mike)
1) Since commit:41a54482 changed timer enabled variable to per-vcpu,
the correlative comment in kvm_timer_enable is useless now.
2) After the kvm module init successfully, the timecounter is always
non-null, so we can remove the checking of timercounter.
Signed-off-by: Longpeng(Mike) <longpeng2@huawei.com>
---
virt/kvm/arm/arch_timer.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 27a1f63..17b8fa5 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -498,17 +498,7 @@ int kvm_timer_enable(struct kvm_vcpu *vcpu)
if (ret)
return ret;
-
- /*
- * There is a potential race here between VCPUs starting for the first
- * time, which may be enabling the timer multiple times. That doesn't
- * hurt though, because we're just setting a variable to the same
- * variable that it already was. The important thing is that all
- * VCPUs have the enabled variable set, before entering the guest, if
- * the arch timers are enabled.
- */
- if (timecounter)
- timer->enabled = 1;
+ timer->enabled = 1;
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* 答复: [PATCH 1/2] drm/amdgpu: disable the VRAM manager on special placements v2
From: Qu, Jim @ 2016-11-09 2:49 UTC (permalink / raw)
To: Christian König,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Zhou, David(ChunMing)
In-Reply-To: <508632be-2cfc-de34-4ad7-68fb518c9d68-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
Reviewed-by: JimQu <Jim.Qu@amd.com>
Thanks
JimQu
________________________________________
发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> 代表 Christian König <deathsimple@vodafone.de>
发送时间: 2016年11月8日 21:09
收件人: amd-gfx@lists.freedesktop.org; Qu, Jim; Zhou, David(ChunMing)
主题: Re: [PATCH 1/2] drm/amdgpu: disable the VRAM manager on special placements v2
Am 04.11.2016 um 12:00 schrieb Christian König:
> From: Christian König <christian.koenig@amd.com>
>
> This disables the VRAM manager when a special placement is requested, otherwise
> we play ping/pong with the buffers on every command submission.
>
> v2: only check lpfn
>
> Signed-off-by: Christian König <christian.koenig@amd.com>
Could anybody give a Reviewed-by for this? I think that is a rather
important performance bug fix.
Regards,
Christian.
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index 180eed7c..d710226 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -108,7 +108,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager *man,
> lpfn = man->size;
>
> if (bo->flags & AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS ||
> - amdgpu_vram_page_split == -1) {
> + place->lpfn || amdgpu_vram_page_split == -1) {
> pages_per_node = ~0ul;
> num_nodes = 1;
> } else {
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH v2 1/3] 99base: add memtrace-ko.sh to debug kernel module large memory consumption
From: Xunlei Pang @ 2016-11-09 2:48 UTC (permalink / raw)
To: Pratyush Anand, Xunlei Pang, Harald Hoyer, Dave Young
Cc: initramfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <beac687a-872a-6b8e-a4da-7dfa54e036c5-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 2016/11/09 at 10:26, Pratyush Anand wrote:
>
>
> On Monday 07 November 2016 11:04 AM, Xunlei Pang wrote:
>> + # Once we get here, the task is being tracked(is loading a module).
>> + # Get the module name.
>> + module_name=${current_module[$pid]}
>> +
>> + if [[ $function = module_put* ]]; then
>
> Also need to check for refcnt=1.
> module_put can also be called by many other places.
We only care about the first one right after module_load was made, for other module_put events, will be skipped by
if ! [[ ${current_module[$pid]} ]]; then
continue
fi
because we will unset current_module[$pid](untrack the task) when parsing the first module_put() after "module_load"
where current_module[$pid](track the task loading module) is set.
>
> Moreover, do we really need to trace module_put? You have filter for module loading applications, and pids for different module load instances would be different, so even if module_put is not tracked, it should work, no?
We need to keep it, lets take an example to illustrate, "insmod mymodule" will hit "module_load" then "module_put"
(even for insert failed cases), then other possible alloc_pages events, init function of the module is called between
"module_load" and the following "module_put" trace point, we only care about alloc_pages events captured in between.
Regards,
Xunlei
>
>> + # Mark the module as loaded when the first module_put event happens after module_load.
>> + echo "${nr_alloc_pages[$module_name]} pages consumed by \"$module_name\""
>> + module_loaded[$module_name]=1
>> + # Module loading finished, so untrack the task.
>> + unset current_module[$pid]
>> + continue
>> + fi
>
> ~Pratyush
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.