On 2/8/21 8:57 PM, Sasha Levin wrote:
On Mon, Feb 08, 2021 at 05:50:21PM +0200, Avi Kivity wrote:
On 05/02/2021 16.26, Greg Kroah-Hartman wrote:
I'm announcing the release of the 4.9.256 kernel.
This, and the 4.4.256 release are a little bit "different" than normal.
This
On 05/02/2021 16.26, Greg Kroah-Hartman wrote:
I'm announcing the release of the 4.9.256 kernel.
This, and the 4.4.256 release are a little bit "different" than normal.
This contains only 1 patch, just the version bump from .255 to .256 which ends
up causing the userspace-visable LINUX_VERSION_
On 12/10/18 2:48 PM, Goldwyn Rodrigues wrote:
On 13:19 09/12, Avi Kivity wrote:
I have an application that receives spurious EIO when running with
RWF_NOWAIT enabled. Removing RWF_NOWAIT causes those EIOs to disappear. The
application uses AIO+DIO, and errors were seen on both xfs and ext4.
I
On 10/12/2018 14.48, Goldwyn Rodrigues wrote:
On 13:19 09/12, Avi Kivity wrote:
I have an application that receives spurious EIO when running with
RWF_NOWAIT enabled. Removing RWF_NOWAIT causes those EIOs to disappear. The
application uses AIO+DIO, and errors were seen on both xfs and ext4
I have an application that receives spurious EIO when running with
RWF_NOWAIT enabled. Removing RWF_NOWAIT causes those EIOs to disappear.
The application uses AIO+DIO, and errors were seen on both xfs and ext4.
I suspect the following code:
/*
* Process one completed BIO. No locks are hel
This reverts commit 4d572d9f46507be8cfe326aa5bc3698babcbdfa7. It is
superceded by the more general
2739b807b0885a09996659be82f813af219c7360 ("aio: only return events
requested in poll_mask() for IOCB_CMD_POLL"). Unfortunately, hch
nacked it on the bug report rather than on the patch itself, so it
w
entfd is almost always ready for a write.
Signed-off-by: Avi Kivity
---
fs/eventfd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/eventfd.c b/fs/eventfd.c
index 61c9514da5e9..ceb1031f1cac 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -154,15 +154,15 @@ static
io_pgetevents() will not change the signal mask. Mark it const
to make it clear and to reduce the need for casts in user code.
Signed-off-by: Avi Kivity
---
include/uapi/linux/aio_abi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/aio_abi.h b/include
On 01/18/2018 07:51 PM, Avi Kivity wrote:
On 01/18/2018 05:46 PM, Jeff Moyer wrote:
FYI, this kernel has issues. It will boot up, but I don't have
networking, and even rebooting doesn't succeed. I'm looking into it.
FWIW, I'm running an older version of this patchset on
On 01/18/2018 05:46 PM, Jeff Moyer wrote:
FYI, this kernel has issues. It will boot up, but I don't have
networking, and even rebooting doesn't succeed. I'm looking into it.
FWIW, I'm running an older version of this patchset on my desktop with
no problems so far.
-Jeff
Christoph Hellwig
On 01/07/2018 04:36 PM, Alan Cox wrote:
I'm interested in participating to working on such a solution, given
that haproxy is severely impacted by "pti=on" and that for now we'll
have to run with "pti=off" on the whole system until a more suitable
solution is found.
I'm still trying to work out
On 01/07/2018 02:29 PM, Theodore Ts'o wrote:
On Sun, Jan 07, 2018 at 11:16:28AM +0200, Avi Kivity wrote:
I think capabilities will work just as well with cgroups. The container
manager will set CAP_PAYLOAD to payload containers; and if those run an init
system or a container ma
On 01/06/2018 10:02 PM, Alan Cox wrote:
I propose to create a new capability, CAP_PAYLOAD, that allows the
system administrator to designate an application as the main workload in
that system. Other processes (like sshd or monitoring daemons) exist to
support it, and so it makes sense to protect
On 01/06/2018 10:24 PM, Willy Tarreau wrote:
Hi Avi,
On Sat, Jan 06, 2018 at 09:33:28PM +0200, Avi Kivity wrote:
Meltdown and Spectre mitigations focus on protecting the kernel from a
hostile userspace. However, it's not a given that the kernel is the most
important target in the syste
Meltdown and Spectre mitigations focus on protecting the kernel from a
hostile userspace. However, it's not a given that the kernel is the most
important target in the system. It is common in server workloads that a
single userspace application contains the valuable data on a system, and
if it
On 12/18/2017 05:28 AM, Goldwyn Rodrigues wrote:
On 12/16/2017 08:49 AM, Avi Kivity wrote:
On 12/14/2017 09:15 PM, Goldwyn Rodrigues wrote:
On 12/14/2017 11:38 AM, Avi Kivity wrote:
I'm looking to add support for RWF_NOWAIT within a linux-aio iocb.
Naturally, I need to detect at ru
On 12/16/2017 08:12 PM, vcap...@pengaru.com wrote:
On Sat, Dec 16, 2017 at 10:03:38AM -0800, vcap...@pengaru.com wrote:
On Sat, Dec 16, 2017 at 04:49:08PM +0200, Avi Kivity wrote:
On 12/14/2017 09:15 PM, Goldwyn Rodrigues wrote:
On 12/14/2017 11:38 AM, Avi Kivity wrote:
I'm looking t
On 12/14/2017 09:15 PM, Goldwyn Rodrigues wrote:
On 12/14/2017 11:38 AM, Avi Kivity wrote:
I'm looking to add support for RWF_NOWAIT within a linux-aio iocb.
Naturally, I need to detect at runtime whether the kernel support
RWF_NOWAIT or not.
The only method I could find was to issue
I'm looking to add support for RWF_NOWAIT within a linux-aio iocb.
Naturally, I need to detect at runtime whether the kernel support
RWF_NOWAIT or not.
The only method I could find was to issue an I/O with RWF_NOWAIT set,
and look for errors. This is somewhat less than perfect:
- from the
On 11/14/2017 06:49 PM, Mathieu Desnoyers wrote:
- On Nov 14, 2017, at 11:08 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Nov 14, 2017 at 05:05:41PM +0100, Peter Zijlstra wrote:
On Tue, Nov 14, 2017 at 03:17:12PM +, Mathieu Desnoyers wrote:
I've tried to create a small sin
On 11/14/2017 05:17 PM, Mathieu Desnoyers wrote:
- On Nov 14, 2017, at 9:53 AM, Avi Kivity a...@scylladb.com wrote:
On 11/13/2017 06:56 PM, Mathieu Desnoyers wrote:
- On Nov 10, 2017, at 4:57 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
- On Nov 10, 2017, at 4
On 11/13/2017 06:56 PM, Mathieu Desnoyers wrote:
- On Nov 10, 2017, at 4:57 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
- On Nov 10, 2017, at 4:36 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
On Fri, Nov 10, 2017 at 1:12 PM, Mathieu Desnoyers
wrote:
x86
On 10/05/2017 07:23 AM, Nicholas Piggin wrote:
On Wed, 4 Oct 2017 14:37:53 -0700
"Paul E. McKenney" wrote:
From: Mathieu Desnoyers
Provide a new command allowing processes to register their intent to use
the private expedited command.
This allows PowerPC to skip the full memory barrier i
On 08/01/2017 01:22 PM, Peter Zijlstra wrote:
If mm cpumask is used, I think it's okay. You can cause quite similar
kind of iteration over CPUs and lots of IPIs, tlb flushes, etc using
munmap/mprotect/etc, or context switch IPIs, etc. Are we reaching the
stage where we're controlling those ki
On 07/31/2017 11:37 AM, Peter Zijlstra wrote:
On Mon, Jul 31, 2017 at 09:03:09AM +0300, Avi Kivity wrote:
I remembered that current->mm does not change when switching to a kernel
task, but my Kernlish is very rusty, or maybe it has changed.
kernel threads do indeed preserve the mm of the
On 07/28/2017 12:02 AM, Mathieu Desnoyers wrote:
- On Jul 27, 2017, at 4:58 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
- On Jul 27, 2017, at 4:37 PM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
On Thu, Jul 27, 2017 at 11:04:13PM +0300, Avi Kivity wrote
On 07/27/2017 10:43 PM, Paul E. McKenney wrote:
On Thu, Jul 27, 2017 at 10:20:14PM +0300, Avi Kivity wrote:
On 07/27/2017 09:12 PM, Paul E. McKenney wrote:
Hello!
Please see below for a prototype sys_membarrier() speedup patch.
Please note that there is some controversy on this subject, so
TED sys_membarrier() call happens within
the same jiffy, all but the first will use synchronize_sched() instead
of synchronize_sched_expedited().
Signed-off-by: Paul E. McKenney
[ paulmck: Fix code style issue pointed out by Boqun Feng. ]
Tested-by: Avi Kivity
C
On 03/16/2017 04:48 PM, Michal Hocko wrote:
On Thu 16-03-17 15:26:54, Avi Kivity wrote:
On 03/16/2017 02:34 PM, Michal Hocko wrote:
On Wed 15-03-17 18:50:32, Avi Kivity wrote:
A user is trying to allocate 1TB of anonymous memory in parallel on 48 cores
(4 NUMA nodes). The kernel ends up
On 03/16/2017 02:34 PM, Michal Hocko wrote:
On Wed 15-03-17 18:50:32, Avi Kivity wrote:
A user is trying to allocate 1TB of anonymous memory in parallel on 48 cores
(4 NUMA nodes). The kernel ends up spinning in isolate_freepages_block().
Which kernel version is that?
A good question; it
A user is trying to allocate 1TB of anonymous memory in parallel on 48
cores (4 NUMA nodes). The kernel ends up spinning in
isolate_freepages_block().
I thought to help it along by using MAP_POPULATE, but then my
MADV_HUGEPAGE won't be seen until after mmap() completes, with pages
already p
On 11/16/2015 07:06 PM, Alex Williamson wrote:
On Wed, 2015-10-28 at 15:21 -0600, Alex Williamson wrote:
There is really no way to safely give a user full access to a DMA
capable device without an IOMMU to protect the host system. There is
also no way to provide DMA translation, for use cases s
On 10/12/2015 07:23 PM, Alex Williamson wrote:
Also, although you think the long option will set the bar high
enough it probably will not satisfy anyone. It is annoying enough, that
I would just carry a patch to remove it the silly requirement.
And the the people who believe
all user mode DMA i
On 10/11/2015 11:57 AM, Michael S. Tsirkin wrote:
On Sun, Oct 11, 2015 at 11:12:14AM +0300, Avi Kivity wrote:
Mixing no-iommu and secure VFIO is
also unsupported, as are any VFIO IOMMU backends other than the
vfio-noiommu backend. Furthermore, unsafe group files are relocated
to /dev/vfio
On 10/09/2015 09:41 PM, Alex Williamson wrote:
There is really no way to safely give a user full access to a PCI
without an IOMMU to protect the host from errant DMA. There is also
no way to provide DMA translation, for use cases such as devices
assignment to virtual machines. However, there
On 10/08/2015 01:26 PM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2015 at 12:19:20PM +0300, Avi Kivity wrote:
On 10/08/2015 11:32 AM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
On 08/10/15 00:05, Michael S. Tsirkin wrote:
On Wed, Oct 07, 2015 at 07
On 10/08/2015 12:16 PM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2015 at 11:46:30AM +0300, Avi Kivity wrote:
On 10/08/2015 10:32 AM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
It is good practice to defend against root oopsing the kernel, but in
On 10/08/2015 11:32 AM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
On 08/10/15 00:05, Michael S. Tsirkin wrote:
On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
That's what I thought as well, but apparently adding msix support t
On 10/08/2015 10:32 AM, Michael S. Tsirkin wrote:
On Thu, Oct 08, 2015 at 08:33:45AM +0300, Avi Kivity wrote:
It is good practice to defend against root oopsing the kernel, but in some
cases it cannot be achieved.
Absolutely. That's one of the issues with these patches. They don'
On 08/10/15 00:05, Michael S. Tsirkin wrote:
On Wed, Oct 07, 2015 at 07:39:16PM +0300, Avi Kivity wrote:
That's what I thought as well, but apparently adding msix support to the
already insecure uio drivers is even worse.
I'm glad you finally agree what these drivers are doing i
On 10/07/2015 07:31 PM, Alex Williamson wrote:
I
guess the no-iommu map would error if the IOVA isn't simply the bus
address of the page mapped.
Of course this is entirely unsafe and this no-iommu driver should taint
the kernel, but it at least standardizes on one userspace API and you're
On 10/07/2015 01:25 PM, Michael S. Tsirkin wrote:
On Tue, Oct 06, 2015 at 07:09:11PM +0300, Avi Kivity wrote:
On 10/06/2015 06:15 PM, Michael S. Tsirkin wrote:
While it is possible that userspace malfunctions and accidentally programs
MSI incorrectly, the risk is dwarfed by the ability of
On 10/06/2015 09:51 PM, Alex Williamson wrote:
On Tue, 2015-10-06 at 18:23 +0300, Avi Kivity wrote:
On 10/06/2015 05:56 PM, Michael S. Tsirkin wrote:
On Tue, Oct 06, 2015 at 05:43:50PM +0300, Vlad Zolotarov wrote:
The only "like VFIO" behavior we implement here is binding
On 10/06/2015 06:15 PM, Michael S. Tsirkin wrote:
While it is possible that userspace malfunctions and accidentally programs
MSI incorrectly, the risk is dwarfed by the ability of userspace to program
DMA incorrectly.
That seems to imply that for the upstream kernel this is not a valid usecase
On 10/06/2015 05:07 PM, Michael S. Tsirkin wrote:
On Tue, Oct 06, 2015 at 03:15:57PM +0300, Avi Kivity wrote:
btw, (2) doesn't really add any insecurity. The user could already poke at
the msix tables (as well as perform DMA); they just couldn't get a useful
interrupt out of them.
On 10/06/2015 05:46 PM, Michael S. Tsirkin wrote:
On Mon, Oct 05, 2015 at 11:28:03AM +0300, Avi Kivity wrote:
Eventfd is a natural enough representation of an interrupt; both kvm and
vfio use it, and are also able to share the eventfd, allowing a vfio
interrupt to generate a kvm interrupt
On 10/06/2015 05:56 PM, Michael S. Tsirkin wrote:
On Tue, Oct 06, 2015 at 05:43:50PM +0300, Vlad Zolotarov wrote:
The only "like VFIO" behavior we implement here is binding the MSI-X
interrupt notification to eventfd descriptor.
There will be more if you add some basic memory protections.
Be
On 10/06/2015 05:30 PM, Michael S. Tsirkin wrote:
On Tue, Oct 06, 2015 at 11:37:59AM +0300, Vlad Zolotarov wrote:
Bus mastering is easily enabled from the user space (taken from DPDK code):
static int
pci_uio_set_bus_master(int dev_fd)
{
uint16_t reg;
int ret;
ret = p
On 10/06/2015 10:33 AM, Stephen Hemminger wrote:
Other than implementation objections, so far the two main arguments
against this reduce to:
1. If you allow UIO ioctl then it opens an API hook for all the crap out
of tree UIO drivers to do what they want.
2. If you allow UIO MSI-X the
On 10/05/2015 02:41 PM, Vlad Zolotarov wrote:
On 10/05/15 13:57, Greg KH wrote:
On Mon, Oct 05, 2015 at 01:48:39PM +0300, Vlad Zolotarov wrote:
On 10/05/15 10:56, Greg KH wrote:
On Mon, Oct 05, 2015 at 10:41:39AM +0300, Vlad Zolotarov wrote:
+struct msix_info {
+int num_irqs;
+stru
On 10/05/2015 01:57 PM, Greg KH wrote:
On Mon, Oct 05, 2015 at 01:48:39PM +0300, Vlad Zolotarov wrote:
On 10/05/15 10:56, Greg KH wrote:
On Mon, Oct 05, 2015 at 10:41:39AM +0300, Vlad Zolotarov wrote:
+struct msix_info {
+ int num_irqs;
+ struct msix_entry *table;
+ struct u
On 10/05/2015 12:49 PM, Greg KH wrote:
On Mon, Oct 05, 2015 at 11:28:03AM +0300, Avi Kivity wrote:
Of course it has to be documented, but this just follows vfio.
Eventfd is a natural enough representation of an interrupt; both kvm and
vfio use it, and are also able to share the eventfd
On 10/05/2015 06:11 AM, Greg KH wrote:
On Sun, Oct 04, 2015 at 11:43:17PM +0300, Vlad Zolotarov wrote:
Add support for MSI and MSI-X interrupt modes:
- Interrupt mode selection order is:
INT#X (for backward compatibility) -> MSI-X -> MSI.
- Add ioctl() commands:
- UIO_PCI
On 10/01/2015 01:28 AM, Stephen Hemminger wrote:
This is a new UIO device driver to allow supporting MSI-X and MSI devices
in userspace. It has been used in environments like VMware and older versions
of QEMU/KVM where no IOMMU support is available.
Why not add msi/msix support to uio_pci_gene
On 08/18/2015 10:57 PM, Paolo Bonzini wrote:
On 18/08/2015 11:30, Avi Kivity wrote:
KVM_USER_EXIT in practice should be so rare (at least with in-kernel
LAPIC) that I don't think this matters. KVM_USER_EXIT is relatively
uninteresting, it only exists to provide an alternative to signals
On 08/17/2015 04:15 PM, Paolo Bonzini wrote:
On 16/08/2015 13:27, Avi Kivity wrote:
On 08/05/2015 07:33 PM, Radim Krčmář wrote:
The guest can use KVM_USER_EXIT instead of a signal-based exiting to
userspace. Availability depends on KVM_CAP_USER_EXIT.
Only x86 is implemented so far.
Signed
On 08/05/2015 07:33 PM, Radim Krčmář wrote:
The guest can use KVM_USER_EXIT instead of a signal-based exiting to
userspace. Availability depends on KVM_CAP_USER_EXIT.
Only x86 is implemented so far.
Signed-off-by: Radim Krčmář
---
v2:
* use vcpu ioctl instead of vm one [4/5]
* shrink k
On 06/12/2015 06:41 PM, Alex Williamson wrote:
On Fri, 2015-06-12 at 00:23 +, Wu, Feng wrote:
-Original Message-
From: Avi Kivity [mailto:avi.kiv...@gmail.com]
Sent: Friday, June 12, 2015 3:59 AM
To: Wu, Feng; k...@vger.kernel.org; linux-kernel@vger.kernel.org
Cc: pbonz
On 06/11/2015 01:51 PM, Feng Wu wrote:
From: Eric Auger
This patch adds and documents a new KVM_DEV_VFIO_DEVICE group
and 2 device attributes: KVM_DEV_VFIO_DEVICE_FORWARD_IRQ,
KVM_DEV_VFIO_DEVICE_UNFORWARD_IRQ. The purpose is to be able
to set a VFIO device IRQ as forwarded or not forwarded.
th
On 05/27/2015 08:05 PM, Paolo Bonzini wrote:
This brings together the remaining parts of SMM. For now I've left the
"weird" interaction between SMM and NMI blocking, and I'm using the same
format for the state save area (which is also the one used by QEMU) as
the RFC.
It builds on the previous
On 05/08/2015 02:20 PM, Paolo Bonzini wrote:
This adds an arch-specific memslot flag that hides slots unless the
VCPU is in system management mode.
Some care is needed in order to limit the overhead of x86_gfn_to_memslot
when compared with gfn_to_memslot. Thankfully, we have __gfn_to_memslot
an
On 04/30/2015 02:36 PM, Paolo Bonzini wrote:
This adds an arch-specific memslot flag that hides slots unless the
VCPU is in system management mode.
Some care is needed in order to limit the overhead of x86_gfn_to_memslot
when compared with gfn_to_memslot. Thankfully, we have __gfn_to_memslot
an
Commit-ID: 763122ade725592402190f5ff3b8d2edf42b87e8
Gitweb: http://git.kernel.org/tip/763122ade725592402190f5ff3b8d2edf42b87e8
Author: Avi Kivity
AuthorDate: Sat, 13 Sep 2014 07:15:05 +0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 17 Sep 2014 17:08:09 -0300
perf tools
On 09/14/2014 12:41 PM, Peter Zijlstra wrote:
On Sat, Sep 13, 2014 at 06:34:37AM +0300, Avi Kivity wrote:
It's not a simple matter of updating the test: the demangler interprets name
beginning with __vt as C++ mangles names, which of course they aren't.
Oh, that'll give cute
Olsa
Cc: Jiri Olsa
Cc: Arnaldo Carvalho de Melo
Signed-off-by: Avi Kivity
---
tools/perf/Documentation/perf-probe.txt | 3 +++
tools/perf/Documentation/perf-report.txt | 3 +++
tools/perf/Documentation/perf-top.txt| 3 +++
tools/perf/builtin-probe.c | 2 ++
tools/perf/bu
Olsa
Cc: Jiri Olsa
Cc: Arnaldo Carvalho de Melo
Signed-off-by: Avi Kivity
---
tools/perf/Documentation/perf-probe.txt | 3 +++
tools/perf/Documentation/perf-report.txt | 3 +++
tools/perf/Documentation/perf-top.txt| 3 +++
tools/perf/builtin-probe.c | 2 ++
tools/perf/bu
On 09/06/2014 09:46 PM, Jiri Olsa wrote:
hi,
Jan Stancek found test 1 breakage, probably caused by following patch:
950b8354716e perf tools: Demangle kernel and kernel module symbols too
it seems to break test 1:
---
[jolsa@krava perf]$ ./perf test -v 1
1: vmlinux symtab matches kallsyms
On 09/02/2014 07:46 PM, Paolo Bonzini wrote:
*/
if (unlikely(real_gfn == UNMAPPED_GVA))
goto error;
@@ -1974,10 +1974,28 @@ static void nested_svm_inject_npf_exit(struct kvm_vcpu
*vcpu,
{
struct vcpu_svm *svm = to_svm(vcpu);
- svm->vmcb->con
On 08/18/2014 01:51 PM, Paolo Bonzini wrote:
Il 18/08/2014 12:26, Avi Kivity ha scritto:
On 08/18/2014 01:20 PM, Paolo Bonzini wrote:
Il 18/08/2014 11:50, Wanpeng Li ha scritto:
fpu_activate hook is introduced by commit 6b52d186 (KVM: Activate fpu on
clts), however, there is no user
On 08/18/2014 01:20 PM, Paolo Bonzini wrote:
Il 18/08/2014 11:50, Wanpeng Li ha scritto:
fpu_activate hook is introduced by commit 6b52d186 (KVM: Activate fpu on
clts), however, there is no user currently, this patch drop it.
Reviewed-by: Yang Zhang
Signed-off-by: Wanpeng Li
---
arch/x86/i
On 07/11/2014 11:40 PM, Paolo Bonzini wrote:
Il 11/07/2014 22:05, Alex Williamson ha scritto:
Which will return 'true' for this whether I specify Aligned or not. If
the standard convention is to make it explicit, I'm happy to add the
extra flag, but I think we already #GP on unaligned as imple
On 06/24/2014 07:45 PM, Marcelo Tosatti wrote:
On Sun, Jun 22, 2014 at 09:02:25PM +0200, Andi Kleen wrote:
First, it's not sufficient to pin the debug store area, you also
have to pin the guest page tables that are used to map the debug
store. But even if you do that, as soon as the guest fork
On 05/30/2014 04:12 AM, Andi Kleen wrote:
From: Andi Kleen
PEBS (Precise Event Bases Sampling) profiling is very powerful,
allowing improved sampling precision and much additional information,
like address or TSX abort profiling. cycles:p and :pp uses PEBS.
This patch enables PEBS profiling i
Commit-ID: 950b8354716eb1f9c0b39777d379efa5f4125c04
Gitweb: http://git.kernel.org/tip/950b8354716eb1f9c0b39777d379efa5f4125c04
Author: Avi Kivity
AuthorDate: Wed, 22 Jan 2014 21:58:46 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 27 Jan 2014 11:47:27 -0300
perf tools
On 01/22/2014 09:58 PM, Avi Kivity wrote:
Some kernels contain C++ code, and thus their symbols need to be demangled.
This allows 'perf kvm top' to generate readable output.
Ping?
Signed-off-by: Avi Kivity
---
tools/perf/util/symbol-elf.c | 2 +-
1 file changed, 1 inser
Some kernels contain C++ code, and thus their symbols need to be demangled.
This allows 'perf kvm top' to generate readable output.
Signed-off-by: Avi Kivity
---
tools/perf/util/symbol-elf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/symbol-elf
On Mon, Nov 25, 2013 at 8:11 AM, Xiao Guangrong
wrote:
>
> On Nov 23, 2013, at 3:14 AM, Marcelo Tosatti wrote:
I'm not really following, but note that parent_pte predates EPT (and
the use of rcu in kvm), so all the complexity that is the result of
trying to pack as many list entries into a cac
On Thu, May 30, 2013 at 7:34 PM, Paolo Bonzini wrote:
> Il 30/05/2013 17:34, Paolo Bonzini ha scritto:
>> Il 30/05/2013 16:35, Paolo Bonzini ha scritto:
>>> The x86-64 extended low-byte registers were fetched correctly from reg,
>>> but not from mod/rm.
>>>
>>> This fixes another bug in the boot o
On Sat, Jan 26, 2013 at 1:46 AM, Stephen Rothwell wrote:
> On Fri, 25 Jan 2013 08:53:58 -0800 Randy Dunlap wrote:
>>
>> Seeing lots of this error on i386:
>>
>> arch/x86/kvm/emulate.c:1016: Error: unsupported for `push'
>
> Caused by commit 9ae9febae950 ("KVM: x86 emulator: covert SETCC to
> fast
of those talented and dedicated hackers, Gleb, who
has authored hundreds of patches in and around KVM.
Avi Kivity (1):
KVM: Retire as maintainer
Gleb Natapov (1):
KVM: taking co-maintenance
CREDITS | 5
On 11/20/2012 02:37 PM, Gleb Natapov wrote:
> Updating MAINTAINERS file.
Applied, thanks.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordom
On 11/20/2012 02:26 PM, Avi Kivity wrote:
> After six and a half years of writing and maintaining KVM, it is time to
> move to new things. Update my MAINTAINERS entry to reflect that.
Gleb, please send an incremental patch (against kvm.git master)
installing yourself as a new co-main
After six and a half years of writing and maintaining KVM, it is time to
move to new things. Update my MAINTAINERS entry to reflect that.
Signed-off-by: Avi Kivity
---
CREDITS | 5 +
MAINTAINERS | 1 -
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/CREDITS b/CREDITS
On 10/31/2012 03:15 PM, Raghavendra K T wrote:
> On 10/31/2012 06:11 PM, Raghavendra K T wrote:
>> On 10/31/2012 06:08 PM, Avi Kivity wrote:
>>> On 10/29/2012 04:07 PM, Raghavendra K T wrote:
>>>> From: Raghavendra K T
>>>>
>>>> Al
On 10/29/2012 04:07 PM, Raghavendra K T wrote:
> From: Raghavendra K T
>
> Also we do not update last boosted vcpu in failure cases.
>
> #endif
> +
> void kvm_vcpu_on_spin(struct kvm_vcpu *me)
> {
> struct kvm *kvm = me->kvm;
> @@ -1727,11 +1727,12 @@ void kvm_vcpu_on_spin(struct kvm_vc
Linus, please pull a few KVM fixes from the repo and tag at:
git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/kvm-3.7-2
Fixing an oops, IPI misrouting in x2apic mode, and not exiting RCU
idle state when receiving an async page fault.
--
On 10/22/2012 04:00 PM, Gleb Natapov wrote:
> Yes, with frame buffer is seems to be the case. One can imagine ROMD
> device that is MMIO on write but still can be accessed for read from
> kernel, but it cannot be coalesced even if coalesced buffer is flushed
> on every exit.
You cannot enable coal
On 10/20/2012 08:20 PM, Borislav Petkov wrote:
> Use __func__ instead of the function name in svm_hardware_enable since
> those things tend to get out of sync. This also slims down printk line
> length in conjunction with using pr_err.
>
> No functionality change.
>
Applied, thanks.
--
error
On 10/19/2012 09:37 AM, Xiao Guangrong wrote:
> After commit b3356bf0dbb349 (KVM: emulator: optimize "rep ins" handling),
> the pieces of io data can be collected and write them to the guest memory
> or MMIO together.
>
> Unfortunately, kvm splits the mmio access into 8 bytes and store them to
> v
On 10/22/2012 03:01 PM, Gleb Natapov wrote:
>> It's time where the guest cannot take interrupts, and time in a high
>> priority guest thread that is spent processing low guest priority requests.
>>
> Proposed fix has exactly same issue. Until all data is transfered to
> userspace no interrupt wil
On 10/22/2012 02:55 PM, Jan Kiszka wrote:
>> Since the userspace change is needed the idea is dead, but if we could
>> implement it I do not see how it can hurt the latency if it would be the
>> only mechanism to use coalesced mmio buffer. Checking that the ring buffer
>> is empty is cheap and if i
On 10/22/2012 02:45 PM, Jan Kiszka wrote:
> On 2012-10-22 14:18, Avi Kivity wrote:
>> On 10/22/2012 01:45 PM, Jan Kiszka wrote:
>>
>>>> Indeed. git pull, recheck and call for kvm_flush_coalesced_mmio_buffer()
>>>> is gone. So this will break new userspace,
On 10/22/2012 02:53 PM, Gleb Natapov wrote:
> On Mon, Oct 22, 2012 at 02:45:37PM +0200, Jan Kiszka wrote:
>> On 2012-10-22 14:18, Avi Kivity wrote:
>> > On 10/22/2012 01:45 PM, Jan Kiszka wrote:
>> >
>> >>> Indeed. git pull, recheck and call for kvm_fl
On 10/19/2012 06:11 PM, Sasha Levin wrote:
> KVM_PV_REASON_PAGE_NOT_PRESENT kicks cpu out of idleness, but we haven't
> marked that spot as an exit from idleness.
>
> Not doing so can cause RCU warnings such as:
>
> [ 732.788386] ===
> [ 732.789803] [ INFO: suspiciou
On 10/22/2012 01:45 PM, Jan Kiszka wrote:
>> Indeed. git pull, recheck and call for kvm_flush_coalesced_mmio_buffer()
>> is gone. So this will break new userspace, not old. By global you mean
>> shared between devices (or memory regions)?
>
> Yes. We only have a single ring per VM, so we cannot f
On 10/21/2012 08:10 PM, Ingo Molnar wrote:
> Ok, looks useful - will someone on the Qemu side script this up
> and integrate it into the kernel in a useful form?
There are going to be as many options as there are users - people will
want different things, like block device assignment (for fs/iosc
On 10/21/2012 05:39 PM, Pekka Enberg wrote:
>
> On Sun, Oct 21, 2012 at 5:02 PM, richard -rw- weinberger
> wrote:
>> qemu supports all these features.
>> E.g. to access the host fs use:
>> qemu ... \
>> -fsdev
>> local,security_model=passthrough,id=fsdev-root,path=/your/root/,readonly
>> \
>>
On 10/12/2012 02:03 AM, Sanagi, Koki wrote:
> This patch changes the way to diplay the vector in trace_msi_set_irq from %x
> to
> %u. Currently, it mismatches another output of ftrace such as kvm_msi_set_irq
> and kvm_inj_virq which uses %u.
>
> Signed-off-by: Koki Sanagi
> ---
> include/trace
On 10/17/2012 07:48 AM, Xiao Guangrong wrote:
> The #PF with PFEC.RSV = 1 indicates that the guest is accessing MMIO, we
> can not fix it if it is caused by delivery event. Reporting internal error
> for this case
Applied, thanks.
--
error compiling committee.c: too many arguments to function
-
On 10/09/2012 08:51 PM, Raghavendra K T wrote:
> Here is the summary:
> We do get good benefit by increasing ple window. Though we don't
> see good benefit for kernbench and sysbench, for ebizzy, we get huge
> improvement for 1x scenario. (almost 2/3rd of ple disabled case).
>
> Let me know if you
1 - 100 of 1618 matches
Mail list logo
