Hi Arnaldo,
On 06/16/2015 09:08 PM, Arnaldo Carvalho de Melo wrote:
Em Tue, Jun 16, 2015 at 08:20:53AM +0530, Hemant Kumar escreveu:
perf kvm {record|report} is used to record and report the performance
profile of any workload on a guest. From the host, we can collect
guest kernel statistics
On Wed, Jun 17, 2015 at 06:47:18PM +0200, Paolo Bonzini wrote:
On 17/06/2015 18:41, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2015 at 06:38:25PM +0200, Paolo Bonzini wrote:
On 17/06/2015 18:34, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2015 at 06:31:32PM +0200, Paolo Bonzini wrote:
I have been looking at it for too long, my concepts
got twisted.
On 06/17/2015 07:56 PM, Mario Smarduch wrote:
Maybe I've been looking at this code too long, but it
appears that on __kvm_vcpu_return we save/restore
fp/simd registers and then change to hyp role. In
between if we get an
On 06/17/2015 04:18 PM, Paolo Bonzini wrote:
On 09/06/2015 06:01, Xiao Guangrong wrote:
On 05/28/2015 01:05 AM, Paolo Bonzini wrote:
This is now very simple to do. The only interesting part is a simple
trick to find the right memslot in gfn_to_rmap, retrieving the address
space from the
On 06/17/2015 04:15 PM, Paolo Bonzini wrote:
On 09/06/2015 05:28, Xiao Guangrong wrote:
-rmapp = gfn_to_rmap(kvm, sp-gfn, PT_PAGE_TABLE_LEVEL);
+slots = kvm_memslots(kvm);
+slot = __gfn_to_memslot(slots, sp-gfn);
+rmapp = __gfn_to_rmap(sp-gfn, PT_PAGE_TABLE_LEVEL, slot);
Maybe I've been looking at this code too long, but it
appears that on __kvm_vcpu_return we save/restore
fp/simd registers and then change to hyp role. In
between if we get an interrupt vCPU may be migrated
to another CPU? Or am I missing something?
Thanks,
- Mario
--
To unsubscribe from this
Hi Marc, this version of the patch works for me.
Tested-by: Vikram Sethi vikr...@codeaurora.org
Thanks,
Vikram
On 06/17/15 04:27, Marc Zyngier wrote:
On VM entry, we disable access to the VFP registers in order to
perform a lazy save/restore of these registers.
On VM exit, we restore access,
On 17/06/2015 19:02, kbuild test robot wrote:
tree: git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
head: 3b1a15b8db95eff1bcd9303057c9415f650c6331
commit: 3b1a15b8db95eff1bcd9303057c9415f650c6331 [94/94] KVM: MTRR: do not
map huge page for non-consistent range
config:
On Wed, 17 Jun 2015 18:30:02 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 06:09:21PM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 17:38:40 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 05:12:57PM +0200, Igor Mammedov wrote:
On
[I resend my message because MLs have refused the first one in HTML]
On 28/05/2015 07:17, Paul Mackerras wrote:
This patch series provides a way to use more of the capacity of each
processor core when running guests configured with threads=1, 2 or 4
on a POWER8 host with HV KVM, without having
[I resend my message because MLs have refused the first one in HTML]
On 28/05/2015 07:17, Paul Mackerras wrote:
This patch series provides a way to use more of the capacity of each
processor core when running guests configured with threads=1, 2 or 4
on a POWER8 host with HV KVM, without having
On Wed, 17 Jun 2015 18:47:18 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
On 17/06/2015 18:41, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2015 at 06:38:25PM +0200, Paolo Bonzini wrote:
On 17/06/2015 18:34, Michael S. Tsirkin wrote:
On Wed, Jun 17, 2015 at 06:31:32PM +0200, Paolo
On Wed, 17 Jun 2015 12:46:09 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 12:37:42PM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 12:11:09 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 10:54:21AM +0200, Igor Mammedov wrote:
On
On 16/06/2015 13:33, Kevin Mulvey wrote:
fix brace spacing
Signed-off-by: Kevin Mulvey kmul...@linux.com
---
virt/kvm/async_pf.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/async_pf.h b/virt/kvm/async_pf.h
index e7ef6447..ec4cfa2 100644
---
Hi Eric,
On 17/06/15 12:51, Eric Auger wrote:
Hi Marc,
On 06/08/2015 07:04 PM, Marc Zyngier wrote:
To allow a HW interrupt to be injected into a guest, we lookup the
guest virtual interrupt in the irq_phys_map rbtree, and if we have
a match, encode both interrupts in the LR.
We also mark
On Wed, 17 Jun 2015 08:31:23 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 12:19:15AM +0200, Igor Mammedov wrote:
On Tue, 16 Jun 2015 23:16:07 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Jun 16, 2015 at 06:33:34PM +0200, Igor Mammedov wrote:
On 11/06/2015 08:05, Bandan Das wrote:
If hardware doesn't support DecodeAssist - a feature that provides
more information about the intercept in the VMCB, KVM decodes the
instruction and then updates the next_rip vmcb control field.
However, NRIP support itself depends on cpuid
Instead of the GIC virtual CPU interface an emulated GICv3 needs to
have accesses to its emulated redistributors trapped in the guest.
Add code to tell the kernel about the mapping if a GICv3 emulation was
requested by the user.
This contains some defines which are not (yet) in the (32 bit)
Since Linux 3.19-rc1 there is a new API to explicitly initialise
the in-kernel GIC emulation by a userland KVM device call.
Use that to tell the kernel we are finished with the GIC
initialisation, since the automatic GIC init will only be provided
as a legacy functionality in the future.
From: Marc Zyngier marc.zyng...@arm.com
On AArch64 system with a GICv2, the GICC range can be aligned
to the last 4k block of a 64k page, ending up straddling two
64k pages. In order not to conflict with the distributor mapping,
allocate two 64k pages to the CPU interface.
Signed-off-by: Marc
From: Marc Zyngier marc.zyng...@arm.com
As of 3.14, KVM/arm supports the creation/configuration of the GIC through
a more generic device API, which is now the preferred way to do so.
Plumb the new API in, and allow the old code to be used as a fallback.
[Andre: Rename some functions on the way
Currently we separate any incoming MMIO request into one of the ARM
memory map regions and take care to spare the GIC.
It turns out that this is unnecessary, as we only have one special
region (the IO port area in the first 64 KByte). The MMIO rbtree
takes care about unhandled MMIO ranges, so we
From: Marc Zyngier marc.zyng...@arm.com
The ARM GIC emulation needs to be told the number of interrupts
it has to support. As commit 1c262fa1dc7bc (kvm tools: irq: make
irq__alloc_line generic) made the interrupt counter private,
add a new accessor returning the number of interrupt lines we've
Currently we unconditionally create a virtual GICv2 in the guest.
Add a --irqchip= parameter to let the user specify a different GIC
type for the guest.
For now we the only other supported type is GICv3.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
arm/aarch64/arm-cpu.c
Currently the ARM GIC checks the number of VCPUs against a fixed
limit, which is GICv2 specific. Don't pretend we know better than the
kernel and let's get rid of that explicit check.
Instead be more relaxed about KVM_CREATE_VCPU failing with EINVAL,
which is the way the kernel communicates having
Hi,
a new version of the GICv3 support series for kvmtool.
I got rid of passing the number of redistributors around kvmtool.
The new patch 06/10 simplifies ARM's MMIO dispatching, so that we no
longer need to know the GIC size at this point. The FDT code uses
base and size values now directly
Extend the vGIC handling code to potentially deal with different IRQ
chip devices instead of hard-coding the GICv2 in.
We extend most vGIC functions to take a type parameter, but still put
GICv2 in at the top for the time being.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
From: Marc Zyngier marc.zyng...@arm.com
In order to reduce the memory usage of large guests (as well
as improve performance), tell KVM about the number of interrupts
we require.
To avoid synchronization with the various device creation,
use a late_init callback to compute the GIC configuration.
Hi Marc,
On 06/08/2015 07:04 PM, Marc Zyngier wrote:
To allow a HW interrupt to be injected into a guest, we lookup the
guest virtual interrupt in the irq_phys_map rbtree, and if we have
a match, encode both interrupts in the LR.
We also mark the interrupt as active at the host distributor
On 06/08/2015 07:03 PM, Marc Zyngier wrote:
Now that struct vgic_lr supports the LR_HW bit and carries a hwirq
field, we can encode that information into the list registers.
This patch provides implementations for both GICv2 and GICv3.
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
On Wed, 17 Jun 2015 13:51:56 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 01:48:03PM +0200, Igor Mammedov wrote:
So far it's kernel limitation and this patch fixes crashes
that users see now, with the rest of patches enabling performance
not to regress.
On Tue, Jun 16, 2015 at 05:35:48PM -0700, Andy Lutomirski wrote:
My sincere apologies for the spam. I send an unholy mixture of the
real patch set and an old poorly split-up patch set, and the result
is incomprehensible. Here's what I meant to send.
After the some recent threads about
Hello!
Yes, I am about to get a v2 ready, but mostly with some fixes. If you
want to work on top of it, I can push a WIP branch to my repo.
Thank you but no need to hurry up. I am busy with other things too. And,
anyway, i work on top of my own branch here.
As Marc mentioned before, this
On Wed, Jun 17, 2015 at 01:48:03PM +0200, Igor Mammedov wrote:
So far it's kernel limitation and this patch fixes crashes
that users see now, with the rest of patches enabling performance
not to regress.
When I say regression I refer to an option to limit the array
size again after
On Wed, Jun 17, 2015 at 12:00:56AM +0200, Igor Mammedov wrote:
On Tue, 16 Jun 2015 23:14:20 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Jun 16, 2015 at 06:33:37PM +0200, Igor Mammedov wrote:
since commit
1d4e7e3 kvm: x86: increase user memory slots to 509
it became
On Wed, 17 Jun 2015 08:34:26 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 12:00:56AM +0200, Igor Mammedov wrote:
On Tue, 16 Jun 2015 23:14:20 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Jun 16, 2015 at 06:33:37PM +0200, Igor Mammedov wrote:
On 17/06/2015 02:36, Andy Lutomirski wrote:
__pvclock_read_cycles had an unnecessary barrier. Get rid of that
barrier and clean up the code by just using rdtsc_ordered().
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: Radim Krcmar rkrc...@redhat.com
Cc: Marcelo Tosatti mtosa...@redhat.com
On 09/06/2015 06:01, Xiao Guangrong wrote:
On 05/28/2015 01:05 AM, Paolo Bonzini wrote:
This is now very simple to do. The only interesting part is a simple
trick to find the right memslot in gfn_to_rmap, retrieving the address
space from the spte role word. The same trick is used in
On 09/06/2015 04:16, Wanpeng Li wrote:
So in the end the patched vcpu_scan_ioapic becomes
if (kvm_apic_hw_enabled(vcpu-arch.apic))
s/kvm_apic_hw_enabled(vcpu-arch.apic)/!kvm_apic_hw_enabled(vcpu-arch.apic)
Right, thanks for the correction.
Paolo
--
To unsubscribe from this list:
On 09/06/2015 05:28, Xiao Guangrong wrote:
-rmapp = gfn_to_rmap(kvm, sp-gfn, PT_PAGE_TABLE_LEVEL);
+slots = kvm_memslots(kvm);
+slot = __gfn_to_memslot(slots, sp-gfn);
+rmapp = __gfn_to_rmap(sp-gfn, PT_PAGE_TABLE_LEVEL, slot);
Why @sp is not available here?
Because the
On Wed, Jun 17, 2015 at 12:19:15AM +0200, Igor Mammedov wrote:
On Tue, 16 Jun 2015 23:16:07 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Tue, Jun 16, 2015 at 06:33:34PM +0200, Igor Mammedov wrote:
Series extends vhost to support upto 509 memory regions,
and adds some
On Tue, Jun 16, 2015 at 06:17:14PM +0100, Will Deacon wrote:
On Mon, Jun 15, 2015 at 12:49:45PM +0100, Andreas Herrmann wrote:
W/o dedicated endianess it's impossible to find reliably a match
e.g. in kernel/virt/kvm/eventfd.c ioeventfd_in_range.
Hmm, but shouldn't this be the endianness of
On Wed, Jun 17, 2015 at 09:28:02AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 08:34:26 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 12:00:56AM +0200, Igor Mammedov wrote:
On Tue, 16 Jun 2015 23:14:20 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 09:33:57AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 08:31:23 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 12:19:15AM +0200, Igor Mammedov wrote:
On Tue, 16 Jun 2015 23:16:07 +0200
Michael S. Tsirkin m...@redhat.com wrote:
PING!
The discussion has suddenly stopped... What is our status? Is ITS v2 patch
being
developed, or what? And do we have some conclusion on irqfd ?
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
-Original Message-
From:
Hello,
some patches to fix at least the build of the new kvmtool for
PowerPC. I could only compile test it so far, so I'd be grateful
if people more familiar with that architecture can have a look
and maybe even test it on actual machines.
Cheers,
Andre.
Andre Przywara (3):
powerpc: implement
For converting the guest/init binary into an object file, we call
the linker binary, setting the endianness to big endian explicitly
when compiling kvmtool for powerpc.
This breaks if the compiler is actually targetting little endian
(which is true for the Debian port, for instance).
Remove the
The powerpc code uses some PAPR hypercalls, of which we need the
hypercall number. Copy the macro definition parts from the kernel's
(private) hvcall.h file and remove the extra tricks formerly used
to be able to include this header file directly.
Signed-off-by: Andre Przywara
For converting the guest/init binary into an object file, we call
the linker binary, setting the endianness to big endian explicitly
when compiling kvmtool for powerpc.
This breaks if the compiler is actually targetting little endian
(which is true for the Debian port, for instance).
Remove the
The powerpc code uses some PAPR hypercalls, of which we need the
hypercall number. Copy the macro definition parts from the kernel's
(private) hvcall.h file and remove the extra tricks formerly used
to be able to include this header file directly.
Signed-off-by: Andre Przywara
Hello,
some patches to fix at least the build of the new kvmtool for
PowerPC. I could only compile test it so far, so I'd be grateful
if people more familiar with that architecture can have a look
and maybe even test it on actual machines.
Cheers,
Andre.
Andre Przywara (3):
powerpc: implement
Instead of referring to the Linux header including the barrier
macros, copy over the rather simple implementation for the PowerPC
barrier instructions kvmtool uses. This fixes build for powerpc.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
Hi,
I just took what kvmtool seems to have
On VM entry, we disable access to the VFP registers in order to
perform a lazy save/restore of these registers.
On VM exit, we restore access, test if we did enable them before,
and save/restore the guest/host registers if necessary. In this
sequence, the FPEXC register is always accessed,
On Tue, Jun 16, 2015 at 05:35:49PM -0700, Andy Lutomirski wrote:
In cdc7957d1954 (x86: move native_read_tsc() offline),
native_read_tsc was moved out of line, presumably for some
now-obsolete vDSO-related reason. Undo it.
The entire rdtsc, shl, or sequence is only 11 bytes, and calls via
On Wed, Jun 17, 2015 at 10:54:21AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 09:39:06 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 09:28:02AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 08:34:26 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, 17 Jun 2015 12:11:09 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 10:54:21AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 09:39:06 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 09:28:02AM +0200, Igor Mammedov wrote:
On
Hello!
Hmmm. You may not have noticed it, but we're actually all are quite busy
at the moment (hint, we're at -rc8, and the next merge window is about
to open).
Ok ok, i do not mind of course. :) Just i expected at least some, quick reply.
It's like
talking to a person while he/she
On Wed, Jun 17, 2015 at 08:17:49AM +0100, Andreas Herrmann wrote:
On Tue, Jun 16, 2015 at 06:17:14PM +0100, Will Deacon wrote:
On Mon, Jun 15, 2015 at 12:49:45PM +0100, Andreas Herrmann wrote:
W/o dedicated endianess it's impossible to find reliably a match
e.g. in
On Tue, Jun 16, 2015 at 05:35:52PM -0700, Andy Lutomirski wrote:
Now that the read_tsc paravirt hook is gone, rdtscll() is just a
wrapper around native_read_tsc(). Unwrap it.
Signed-off-by: Andy Lutomirski l...@kernel.org
---
arch/x86/boot/compressed/aslr.c | 2 +-
On Wed, 17 Jun 2015 09:39:06 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 09:28:02AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 08:34:26 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 12:00:56AM +0200, Igor Mammedov wrote:
On
From: Suzuki K. Poulose suzuki.poul...@arm.com
This patch adds a generic ARM v8 KVM target cpu type for use
by the new CPUs which eventualy ends up using the common sys_reg
table. For backward compatibility the existing targets have been
preserved. Any new target CPU that can be covered by
On 17/06/15 10:21, Pavel Fedin wrote:
PING!
The discussion has suddenly stopped... What is our status? Is ITS v2 patch
being
developed, or what? And do we have some conclusion on irqfd ?
Hmmm. You may not have noticed it, but we're actually all are quite busy
at the moment (hint, we're at
On Wed, Jun 17, 2015 at 12:37:42PM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 12:11:09 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 10:54:21AM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 09:39:06 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On 17.06.15 12:15, Will Deacon wrote:
On Wed, Jun 17, 2015 at 10:43:48AM +0100, Andre Przywara wrote:
Instead of referring to the Linux header including the barrier
macros, copy over the rather simple implementation for the PowerPC
barrier instructions kvmtool uses. This fixes build for
Здравствуй Pavel,
On 06/17/2015 10:21 AM, Pavel Fedin wrote:
PING!
The discussion has suddenly stopped... What is our status? Is ITS v2 patch
being
developed, or what?
Yes, I am about to get a v2 ready, but mostly with some fixes. If you
want to work on top of it, I can push a WIP branch
On 17/06/2015 08:34, Michael S. Tsirkin wrote:
Also - 509?
userspace memory slots in terms of KVM, I made it match
KVM's allotment of memory slots for userspace side.
Maybe KVM has its reasons for this #.
Nice power of two (512) - number of reserved slots required by Intel's
On Tue, Jun 16, 2015 at 05:35:50PM -0700, Andy Lutomirski wrote:
The only caller was kvm's read_tsc. The only difference between
vget_cycles and native_read_tsc was that vget_cycles returned zero
instead of crashing on TSC-less systems. KVM's already checks
vclock_mode before calling that
+ paravirt list.
On Tue, Jun 16, 2015 at 05:35:51PM -0700, Andy Lutomirski wrote:
We've had read_tsc and read_tscp paravirt hooks since the very
beginning of paravirt, i.e., d3561b7fa0fb ([PATCH] paravirt: header
and stubs for paravirtualisation). AFAICT the only paravirt guest
On Wed, Jun 17, 2015 at 10:43:50AM +0100, Andre Przywara wrote:
The powerpc code uses some PAPR hypercalls, of which we need the
hypercall number. Copy the macro definition parts from the kernel's
(private) hvcall.h file and remove the extra tricks formerly used
to be able to include this
On Wed, Jun 17, 2015 at 10:43:50AM +0100, Andre Przywara wrote:
The powerpc code uses some PAPR hypercalls, of which we need the
hypercall number. Copy the macro definition parts from the kernel's
(private) hvcall.h file and remove the extra tricks formerly used
to be able to include this
On Wed, Jun 17, 2015 at 10:43:48AM +0100, Andre Przywara wrote:
Instead of referring to the Linux header including the barrier
macros, copy over the rather simple implementation for the PowerPC
barrier instructions kvmtool uses. This fixes build for powerpc.
Signed-off-by: Andre Przywara
On 17/06/15 12:53, Eric Auger wrote:
On 06/08/2015 07:03 PM, Marc Zyngier wrote:
Now that struct vgic_lr supports the LR_HW bit and carries a hwirq
field, we can encode that information into the list registers.
This patch provides implementations for both GICv2 and GICv3.
Signed-off-by:
On 17/06/15 12:21, Andre Przywara wrote:
Currently we separate any incoming MMIO request into one of the ARM
memory map regions and take care to spare the GIC.
It turns out that this is unnecessary, as we only have one special
region (the IO port area in the first 64 KByte). The MMIO rbtree
On 17/06/15 12:21, Andre Przywara wrote:
Extend the vGIC handling code to potentially deal with different IRQ
chip devices instead of hard-coding the GICv2 in.
We extend most vGIC functions to take a type parameter, but still put
GICv2 in at the top for the time being.
Signed-off-by: Andre
On 17/06/15 12:22, Andre Przywara wrote:
Instead of the GIC virtual CPU interface an emulated GICv3 needs to
have accesses to its emulated redistributors trapped in the guest.
Add code to tell the kernel about the mapping if a GICv3 emulation was
requested by the user.
This contains some
On 17/06/2015 15:13, Michael S. Tsirkin wrote:
Considering userspace can be malicious, I guess yes.
I don't think it's a valid concern in this case,
setting limit back from 509 to 64 will not help here in any way,
userspace still can create as many vhost instances as it needs
to
Ref to prefious version discussion:
[PATCH 0/5] vhost: support upto 509 memory regions
http://www.spinics.net/lists/kvm/msg117654.html
Chagelog v1-v2:
* fix spelling errors
* move vhost: support upto 509 memory regions to the end of queue
* move kvfree() form 1/6 to 2/6 where it belongs
On 17 June 2015 at 12:53, Eric Auger eric.au...@linaro.org wrote:
shouldn't we test somewhere that the hwirq is between 16 and 1019.
Not directly related, but that reminds me that I noticed the
other day that we have VGIC_MAX_IRQS = 1024 (and use that as a
guard on how many irqs we let userspace
On 17/06/15 12:22, Andre Przywara wrote:
Currently we unconditionally create a virtual GICv2 in the guest.
Add a --irqchip= parameter to let the user specify a different GIC
type for the guest.
For now we the only other supported type is GICv3.
Superfluous we.
Also, spelling out the expected
with large number of memory regions we could end up with
high order allocations and kmalloc could fail if
host is under memory pressure.
Considering that memory regions array is used on hot path
try harder to allocate using kmalloc and if it fails resort
to vmalloc.
It's still better than just
that brings down translate_desc() cost to around 210ns
if accessed descriptors are from the same memory region.
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
that's what netperf/iperf workloads were during testing.
---
drivers/vhost/vhost.c | 16 +---
drivers/vhost/vhost.h |
On 17/06/2015 09:47, Paolo Bonzini wrote:
On 17/06/2015 02:36, Andy Lutomirski wrote:
__pvclock_read_cycles had an unnecessary barrier. Get rid of that
barrier and clean up the code by just using rdtsc_ordered().
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: Radim Krcmar
On 17/06/2015 02:35, Andy Lutomirski wrote:
The only caller was kvm's read_tsc. The only difference between
vget_cycles and native_read_tsc was that vget_cycles returned zero
instead of crashing on TSC-less systems. KVM's already checks
vclock_mode before calling that function, so the
On 17/06/15 14:21, Peter Maydell wrote:
On 17 June 2015 at 12:53, Eric Auger eric.au...@linaro.org wrote:
shouldn't we test somewhere that the hwirq is between 16 and 1019.
Not directly related, but that reminds me that I noticed the
other day that we have VGIC_MAX_IRQS = 1024 (and use that
Hi Marc,
On 06/17/2015 01:48 PM, Marc Zyngier wrote:
On 17/06/15 12:21, Andre Przywara wrote:
Currently we separate any incoming MMIO request into one of the ARM
memory map regions and take care to spare the GIC.
It turns out that this is unnecessary, as we only have one special
region (the
by default translation of virtqueue descriptors is done with
caching enabled, but caching will add only extra cost
in cases of trashing workload where majority descriptors
are translated to different memory regions.
So add an option to allow exclude cache miss cost for such cases.
Performance
For default region layouts performance stays the same
as linear search i.e. it takes around 210ns average for
translate_desc() that inlines find_region().
But it scales better with larger amount of regions,
235ns BS vs 300ns LS with 55 memory regions
and it will be about the same values when
On 17/06/2015 13:11, Borislav Petkov wrote:
peterz reminded me that I'm lazy actually and don't reply to each patch :)
So, I like it, looks good, nice cleanup. It boots on my guest here - I
haven't done any baremetal testing though. Let's give people some more
time to look at it...
Same
On 11/06/2015 15:18, Denis V. Lunev wrote:
From: Andrey Smetanin asmeta...@virtuozzo.com
Windows 2012 guests can notify hypervisor about occurred guest crash
(Windows bugcheck(BSOD)) by writing specific Hyper-V msrs. This patch does
handling of this MSR's by KVM and sending notification to
when translating descriptors they are typically less than
memory region that holds them and translated into 1 iov
entry, so it's not nessesary to check remaining length
twice and calculate used length and next address
in such cases.
replace a remaining length and 'size' increment branches
with a
On 06/17/2015 01:53 PM, Marc Zyngier wrote:
On 17/06/15 12:21, Andre Przywara wrote:
Currently the ARM GIC checks the number of VCPUs against a fixed
limit, which is GICv2 specific. Don't pretend we know better than the
kernel and let's get rid of that explicit check.
Instead be more relaxed
On 17/06/15 12:21, Andre Przywara wrote:
Currently the ARM GIC checks the number of VCPUs against a fixed
limit, which is GICv2 specific. Don't pretend we know better than the
kernel and let's get rid of that explicit check.
Instead be more relaxed about KVM_CREATE_VCPU failing with EINVAL,
On Wed, Jun 17, 2015 at 02:23:39PM +0200, Igor Mammedov wrote:
On Wed, 17 Jun 2015 13:51:56 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jun 17, 2015 at 01:48:03PM +0200, Igor Mammedov wrote:
So far it's kernel limitation and this patch fixes crashes
that users see now,
since commit
1d4e7e3 kvm: x86: increase user memory slots to 509
it became possible to use a bigger amount of memory
slots, which is used by memory hotplug for
registering hotplugged memory.
However QEMU crashes if it's used with more than ~60
pc-dimm devices and vhost-net since host kernel
in
On 11/06/2015 15:18, Denis V. Lunev wrote:
From: Andrey Smetanin asmeta...@virtuozzo.com
KVM Hyper-V based guests can notify hypervisor about
occurred guest crash. This patch does handling of KVM crash event
by sending to libvirt guest panic event that allows to gather
guest crash dump by
On 17/06/15 14:49, Andre Przywara wrote:
Hi Marc,
On 06/17/2015 01:48 PM, Marc Zyngier wrote:
On 17/06/15 12:21, Andre Przywara wrote:
Currently we separate any incoming MMIO request into one of the ARM
memory map regions and take care to spare the GIC.
It turns out that this is
On Wed, Jun 17, 2015 at 03:20:44PM +0200, Paolo Bonzini wrote:
On 17/06/2015 15:13, Michael S. Tsirkin wrote:
Considering userspace can be malicious, I guess yes.
I don't think it's a valid concern in this case,
setting limit back from 509 to 64 will not help here in any way,
Hi Marc,
On 06/08/2015 07:04 PM, Marc Zyngier wrote:
So far, the only use of the HW interrupt facility is the timer,
implying that the active state is context-switched for each vcpu,
as the device is is shared across all vcpus.
s/is//
This does not work for a device that has been assigned to
On 17/06/15 16:11, Eric Auger wrote:
Hi Marc,
On 06/08/2015 07:04 PM, Marc Zyngier wrote:
So far, the only use of the HW interrupt facility is the timer,
implying that the active state is context-switched for each vcpu,
as the device is is shared across all vcpus.
s/is//
This does not work
Reviewed-by: Eric Auger eric.au...@linaro.org
On 06/08/2015 07:04 PM, Marc Zyngier wrote:
In order to control the active state of an interrupt, introduce
a pair of accessors allowing the state to be set/queried.
This only affects the logical state, and the HW state will only be
applied at
1 - 100 of 114 matches
Mail list logo
