On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
Hello ARM virt maintainers,
I'd like to start a discussion about supporting virt-what[1]. virt-what
allows userspace to determine if the system it's running on is running
in a guest, and of what type (KVM, Xen, etc.). Despite it
On Thu, Mar 26, 2015 at 5:47 AM, Bandan Das b...@redhat.com wrote:
Hi Andrey,
Andrey Korolyov and...@xdel.ru writes:
On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov and...@xdel.ru wrote:
For now, it looks like bug have a mixed Murphy-Heisenberg nature, as
it appearance is very rare
Just like svm, we'd better make this more readable as well since
virt/kvm already have some common functions with same name.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
arch/x86/kvm/vmx.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git
On Wed, Mar 25, 2015 at 04:22:03PM -0700, Andy Lutomirski wrote:
On Wed, Mar 25, 2015 at 4:13 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 03:48:02PM -0700, Andy Lutomirski wrote:
On Wed, Mar 25, 2015 at 3:41 PM, Marcelo Tosatti mtosa...@redhat.com
wrote:
On
Hi Marcelo,
On 25/03/15 21:59, Marcelo Tosatti wrote:
On Wed, Mar 25, 2015 at 05:09:13PM +, Marc Zyngier wrote:
On 23/03/15 15:58, Andre Przywara wrote:
In kvm_destroy_vm() we call kvm_io_bus_destroy() pretty early,
especially before calling kvm_arch_destroy_vm(). To avoid
unregistering
On 2015/3/27 9:31, Marcelo Tosatti wrote:
On Wed, Mar 25, 2015 at 05:09:13PM +, Marc Zyngier wrote:
On 23/03/15 15:58, Andre Przywara wrote:
In kvm_destroy_vm() we call kvm_io_bus_destroy() pretty early,
especially before calling kvm_arch_destroy_vm(). To avoid
unregistering devices from
We can tell when a secondary thread has finished running a guest by
the fact that it clears its kvm_hstate.kvm_vcpu pointer, so there
is no real need for the nap_count field in the kvmppc_vcore struct.
This changes kvmppc_wait_for_nap to poll the kvm_hstate.kvm_vcpu
pointers of the secondary
This is the rest of my current patch queue for HV KVM on PPC. This
series is based on Alex Graf's kvm-ppc-queue branch.
The last patch in this series needs a definition of PPC_MSGCLR that is
added by the patch powerpc/powernv: Fixes for hypervisor doorbell
handling, which has now gone upstream
Previously, if kvmppc_run_core() was running a VCPU that needed a VPA
update (i.e. one of its 3 virtual processor areas needed to be pinned
in memory so the host real mode code can update it on guest entry and
exit), we would drop the vcore lock and do the update there and then.
Future changes
* Remove unused kvmppc_vcore::n_busy field.
* Remove setting of RMOR, since it was only used on PPC970 and the
PPC970 KVM support has been removed.
* Don't use r1 or r2 in setting the runlatch since they are
conventionally reserved for other things; use r0 instead.
* Streamline the code a
Currently, the entry_exit_count field in the kvmppc_vcore struct
contains two 8-bit counts, one of the threads that have started entering
the guest, and one of the threads that have started exiting the guest.
This changes it to an entry_exit_map field which contains two bitmaps
of 8 bits each.
Previously, if kvmppc_run_core() was running a VCPU that needed a VPA
update (i.e. one of its 3 virtual processor areas needed to be pinned
in memory so the host real mode code can update it on guest entry and
exit), we would drop the vcore lock and do the update there and then.
Future changes
We can tell when a secondary thread has finished running a guest by
the fact that it clears its kvm_hstate.kvm_vcpu pointer, so there
is no real need for the nap_count field in the kvmppc_vcore struct.
This changes kvmppc_wait_for_nap to poll the kvm_hstate.kvm_vcpu
pointers of the secondary
This uses msgsnd where possible for signalling other threads within
the same core on POWER8 systems, rather than IPIs through the XICS
interrupt controller. This includes waking secondary threads to run
the guest, the interrupts generated by the virtual XICS, and the
interrupts to bring the other
* Remove unused kvmppc_vcore::n_busy field.
* Remove setting of RMOR, since it was only used on PPC970 and the
PPC970 KVM support has been removed.
* Don't use r1 or r2 in setting the runlatch since they are
conventionally reserved for other things; use r0 instead.
* Streamline the code a
Currently, the entry_exit_count field in the kvmppc_vcore struct
contains two 8-bit counts, one of the threads that have started entering
the guest, and one of the threads that have started exiting the guest.
This changes it to an entry_exit_map field which contains two bitmaps
of 8 bits each.
This creates a debugfs directory for each HV guest (assuming debugfs
is enabled in the kernel config), and within that directory, a file
by which the contents of the guest's HPT (hashed page table) can be
read. The directory is named vm, where is the PID of the
process that created the
Rather than calling cond_resched() in kvmppc_run_core() before doing
the post-processing for the vcpus that we have just run (that is,
calling kvmppc_handle_exit_hv(), kvmppc_set_timer(), etc.), we now do
that post-processing before calling cond_resched(), and that post-
processing is moved out
This is the rest of my current patch queue for HV KVM on PPC. This
series is based on Alex Graf's kvm-ppc-queue branch.
The last patch in this series needs a definition of PPC_MSGCLR that is
added by the patch powerpc/powernv: Fixes for hypervisor doorbell
handling, which has now gone upstream
On entry to the guest, secondary threads now wait for the primary to
switch the MMU after loading up most of their state, rather than before.
This means that the secondary threads get into the guest sooner, in the
common case where the secondary threads get to kvmppc_hv_entry before
the primary
This replaces the assembler code for kvmhv_commence_exit() with C code
in book3s_hv_builtin.c. It also moves the IPI sending code that was
in book3s_hv_rm_xics.c into a new kvmhv_rm_send_ipi() function so it
can be used by kvmhv_commence_exit() as well as icp_rm_set_vcpu_irq().
Signed-off-by:
When running a multi-threaded guest and vcpu 0 in a virtual core
is not running in the guest (i.e. it is busy elsewhere in the host),
thread 0 of the physical core will switch the MMU to the guest and
then go to nap mode in the code at kvm_do_nap. If the guest sends
an IPI to thread 0 using the
This uses msgsnd where possible for signalling other threads within
the same core on POWER8 systems, rather than IPIs through the XICS
interrupt controller. This includes waking secondary threads to run
the guest, the interrupts generated by the virtual XICS, and the
interrupts to bring the other
This replaces the assembler code for kvmhv_commence_exit() with C code
in book3s_hv_builtin.c. It also moves the IPI sending code that was
in book3s_hv_rm_xics.c into a new kvmhv_rm_send_ipi() function so it
can be used by kvmhv_commence_exit() as well as icp_rm_set_vcpu_irq().
Signed-off-by:
Rather than calling cond_resched() in kvmppc_run_core() before doing
the post-processing for the vcpus that we have just run (that is,
calling kvmppc_handle_exit_hv(), kvmppc_set_timer(), etc.), we now do
that post-processing before calling cond_resched(), and that post-
processing is moved out
On entry to the guest, secondary threads now wait for the primary to
switch the MMU after loading up most of their state, rather than before.
This means that the secondary threads get into the guest sooner, in the
common case where the secondary threads get to kvmppc_hv_entry before
the primary
This creates a debugfs directory for each HV guest (assuming debugfs
is enabled in the kernel config), and within that directory, a file
by which the contents of the guest's HPT (hashed page table) can be
read. The directory is named vm, where is the PID of the
process that created the
When running a multi-threaded guest and vcpu 0 in a virtual core
is not running in the guest (i.e. it is busy elsewhere in the host),
thread 0 of the physical core will switch the MMU to the guest and
then go to nap mode in the code at kvm_do_nap. If the guest sends
an IPI to thread 0 using the
This arranges for threads that are napping due to their vcpu having
ceded or due to not having a vcpu to wake up at the end of the guest's
timeslice without having to be poked with an IPI. We do that by
arranging for the decrementer to contain a value no greater than the
number of timebase ticks
This reads the timebase at various points in the real-mode guest
entry/exit code and uses that to accumulate total, minimum and
maximum time spent in those parts of the code. Currently these
times are accumulated per vcpu in 5 parts of the code:
* rm_entry - time taken from the start of
This arranges for threads that are napping due to their vcpu having
ceded or due to not having a vcpu to wake up at the end of the guest's
timeslice without having to be poked with an IPI. We do that by
arranging for the decrementer to contain a value no greater than the
number of timebase ticks
This reads the timebase at various points in the real-mode guest
entry/exit code and uses that to accumulate total, minimum and
maximum time spent in those parts of the code. Currently these
times are accumulated per vcpu in 5 parts of the code:
* rm_entry - time taken from the start of
On 23 March 2015 at 17:05, Alex Bennée alex.ben...@linaro.org wrote:
As there is logic to deal with the difference between edge and level
triggered interrupts in the kernel we must ensure it knows the
configuration of the IRQs before we restore the pending state.
Signed-off-by: Alex Bennée
On 23 March 2015 at 17:05, Alex Bennée alex.ben...@linaro.org wrote:
+/* Advanced SIMD and FP registers
+ * We map Qn = regs[2n+1]:regs[2n]
+ */
+for (i = 0; i 32; i++) {
+int rd = i 1;
+float128 fp_val = make_float128(env-vfp.regs[rd + 1],
+
On 23 March 2015 at 17:05, Alex Bennée alex.ben...@linaro.org wrote:
I was getting very confused about the duplication of state so wanted to
make it explicit.
Signed-off-by: Alex Bennée alex.ben...@linaro.org
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 083211c..6dc1799 100644
On 23 March 2015 at 17:05, Alex Bennée alex.ben...@linaro.org wrote:
The current code was negatively indexing the cpu state array and not
synchronizing banked spsr register state with the current mode's spsr
state, causing occasional failures with migration.
Some munging is done to take care
Ah, this was gdb (QEMU has its own monitor and it sums the CS base if
you use $pc, but not if you write an absolute address).
Thanks, that's useful to know! I didn't realize QEMU supported this.
However, the trace then shows a crash (triple fault) at 0x63, not 0x58.
Please run info
On Thu, Mar 26, 2015 at 08:08:52PM +0300, Andrey Korolyov wrote:
On Thu, Mar 26, 2015 at 8:06 PM, Kevin O'Connor ke...@koconnor.net wrote:
On Thu, Mar 26, 2015 at 07:48:09PM +0300, Andrey Korolyov wrote:
On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor ke...@koconnor.net wrote:
I'm not sure
2015-03-26 20:08+0300, Andrey Korolyov:
KVM internal error. Suberror: 2
extra data[0]: 80ef
extra data[1]: 8b0d
Btw. does this part ever change?
I see that first report had:
KVM internal error. Suberror: 2
extra data[0]: 80d1
extra data[1]: 8b0d
Was that a Windows
On 26/03/2015 17:08, James Hogan wrote:
This patchset primarily adds guest Floating Point Unit (FPU) and MIPS
SIMD Architecture (MSA) support to MIPS KVM, by enabling the host
FPU/MSA while in guest mode.
This patchset depends on Paul Burton's FP/MSA fixes patchset, which will
make it
The trace file is available here:
http://oss.xes-inc.com/xtmp/trace-pcimem-memtest86-reset.dat.gz
Run QEMU with -no-reboot -no-shutdown -monitor stdio. When it
crashes, run info registers and then x/70i 0, and email the output.
QEMU output:
---[snip]---
$ qemu-system-x86_64
On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor ke...@koconnor.net wrote:
On Thu, Mar 26, 2015 at 04:58:07PM +0100, Radim Krčmář wrote:
2015-03-25 20:05-0400, Kevin O'Connor:
On Thu, Mar 26, 2015 at 02:35:58AM +0300, Andrey Korolyov wrote:
Thanks, strangely the reboot is always failing now
2015-03-26 12:36-0400, Kevin O'Connor:
On Thu, Mar 26, 2015 at 04:58:07PM +0100, Radim Krčmář wrote:
Notice the 0xef. My best hypothesis so far is that we fail at resetting
devices, and 0xef is LOCAL_TIMER_VECTOR from Linux before we rebooted.
(The bug happens at the first place that
2015-03-26 19:48+0300, Andrey Korolyov:
I`ll post a sample event
capture with and without Radim`s proposed patch maybe today or
tomorrow.
Thanks.
The patch doesn't change runtime behavior, it just adds another data
field to the error report, so
Add KVM register numbers for the MIPS SIMD Architecture (MSA) registers,
and implement access to them with the KVM_GET_ONE_REG / KVM_SET_ONE_REG
ioctls when the MSA capability is enabled (exposed in a later patch) and
present in the guest according to its Config3.MSAP bit.
The MSA vector
Now that the code is in place for KVM to support MIPS SIMD Architecutre
(MSA) in MIPS guests, wire up the new KVM_CAP_MIPS_MSA capability.
For backwards compatibility, the capability must be explicitly enabled
in order to detect or make use of MSA from the guest.
The capability is not supported
Now that the code is in place for KVM to support FPU in MIPS KVM guests,
wire up the new KVM_CAP_MIPS_FPU capability.
For backwards compatibility, the capability must be explicitly enabled
in order to detect or make use of the FPU from the guest.
Signed-off-by: James Hogan james.ho...@imgtec.com
This patchset primarily adds guest Floating Point Unit (FPU) and MIPS
SIMD Architecture (MSA) support to MIPS KVM, by enabling the host
FPU/MSA while in guest mode.
This patchset depends on Paul Burton's FP/MSA fixes patchset, which will
make it into 4.0. I've only included the 3 patches (15, 19,
On 26/03/2015 17:52, Nate Case wrote:
I don't think the x/70i 0 output reflected where the CPU was actually
executing? Based on the CS:IP of 9020:0058 (0x90258), shouldn't I be
dumping from around 0x90200 instead? gdb gets easily confused here
Ah, this was gdb (QEMU has its own monitor and
On 23 March 2015 at 17:05, Alex Bennée alex.ben...@linaro.org wrote:
This adds the saving and restore of the current Multi-Processing state
of the machine. While the KVM_GET/SET_MP_STATE API exposes a number of
potential states for x86 we only use two for ARM. Either the process is
running or
On 26/03/2015 17:01, Nate Case wrote:
When KVM acceleration is enabled, SeaBIOS seems to function fine
running out of PCI memory space, but booting the OS resets.
Specifically, the following happens (I'll stick with the memtest86+
5.01 test case for simplicity):
please include a trace
On Thu, Mar 26, 2015 at 04:58:07PM +0100, Radim Krčmář wrote:
2015-03-25 20:05-0400, Kevin O'Connor:
On Thu, Mar 26, 2015 at 02:35:58AM +0300, Andrey Korolyov wrote:
Thanks, strangely the reboot is always failing now and always reaching
seabios greeting. May be prints straightened up a
On Thu, Mar 26, 2015 at 8:06 PM, Kevin O'Connor ke...@koconnor.net wrote:
On Thu, Mar 26, 2015 at 07:48:09PM +0300, Andrey Korolyov wrote:
On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor ke...@koconnor.net wrote:
I'm not sure if the crash always happens at the int $0x19 location
though.
On 26/03/2015 17:34, Nate Case wrote:
0x52:addal,dh
0x54:popcx
0x55:clc
0x56:addal,dh
= 0x58:cs
0x59:call 0xf05c
0x5c:shrbh,cl
0x5e:addal,dh
0x60:addax,0xcf
- Original Message -
On 26/03/2015 17:34, Nate Case wrote:
0x52:addal,dh
0x54:popcx
0x55:clc
0x56:addal,dh
= 0x58:cs
0x59:call 0xf05c
0x5c:shrbh,cl
0x5e:addal,dh
On Thu, Mar 26, 2015 at 8:18 PM, Kevin O'Connor ke...@koconnor.net wrote:
On Thu, Mar 26, 2015 at 08:08:52PM +0300, Andrey Korolyov wrote:
On Thu, Mar 26, 2015 at 8:06 PM, Kevin O'Connor ke...@koconnor.net wrote:
On Thu, Mar 26, 2015 at 07:48:09PM +0300, Andrey Korolyov wrote:
On Thu, Mar
2015-03-26 11:51-0700, Andy Lutomirski:
On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 04:22:03PM -0700, Andy Lutomirski wrote:
Suppose we start out with all vcpus agreeing on their pvti and perfect
invariant TSCs. Now the host updates
On Wed, Mar 25, 2015 at 03:47:39PM -0400, Konrad Rzeszutek Wilk wrote:
Ah nice. That could be spun out as a seperate patch to optimize the existing
ticket locks I presume.
Yes I suppose we can do something similar for the ticket and patch in
the right increment. We'd need to restructure the
2015-03-26 21:24+0300, Andrey Korolyov:
On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář rkrc...@redhat.com wrote:
2015-03-26 20:08+0300, Andrey Korolyov:
KVM internal error. Suberror: 2
extra data[0]: 80ef
extra data[1]: 8b0d
Btw. does this part ever change?
I see that first
On Thu, Mar 26, 2015 at 07:48:09PM +0300, Andrey Korolyov wrote:
On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor ke...@koconnor.net wrote:
I'm not sure if the crash always happens at the int $0x19 location
though. Andrey, does the crash always happen with EIP=d331 and/or
with Code=... cd
On 26 March 2015 at 19:49, Ard Biesheuvel ard.biesheu...@linaro.org wrote:
On 26 March 2015 at 19:45, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Thu, 26 Mar 2015, Andrew Jones wrote:
On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
Hello ARM virt maintainers,
On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 04:22:03PM -0700, Andy Lutomirski wrote:
On Wed, Mar 25, 2015 at 4:13 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 03:48:02PM -0700, Andy Lutomirski wrote:
On Wed,
On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář rkrc...@redhat.com wrote:
2015-03-26 20:08+0300, Andrey Korolyov:
KVM internal error. Suberror: 2
extra data[0]: 80ef
extra data[1]: 8b0d
Btw. does this part ever change?
I see that first report had:
KVM internal error. Suberror: 2
On 26 March 2015 at 19:45, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Thu, 26 Mar 2015, Andrew Jones wrote:
On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
Hello ARM virt maintainers,
I'd like to start a discussion about supporting virt-what[1]. virt-what
On Thu, 26 Mar 2015, Andrew Jones wrote:
On Wed, Mar 25, 2015 at 10:44:42AM +0100, Andrew Jones wrote:
Hello ARM virt maintainers,
I'd like to start a discussion about supporting virt-what[1]. virt-what
allows userspace to determine if the system it's running on is running
in a guest,
On 03/26/2015 09:53 PM, Marc Zyngier wrote:
On Thu, 26 Mar 2015 14:39:36 +
Andre Przywara andre.przyw...@arm.com wrote:
Currently we handle the redistributor registers in two separate MMIO
regions, one for the overall behaviour and SPIs and one for the
SGIs/PPIs. That latter forces the
On 03/26/2015 10:06 PM, Marc Zyngier wrote:
On Thu, 26 Mar 2015 14:39:37 +
Andre Przywara andre.przyw...@arm.com wrote:
Using the framework provided by the recent vgic.c changes, we
register a kvm_io_bus device on mapping the virtual GICv3 resources.
The distributor mapping is pretty
On 11/03/2015 15:44, James Hogan wrote:
Add KVM register numbers for the MIPS FPU registers, and implement
access to them with the KVM_GET_ONE_REG / KVM_SET_ONE_REG ioctls when
the FPU capability is enabled (exposed in a later patch) and present in
the guest according to its Config1.FP bit.
On 11/03/2015 15:44, James Hogan wrote:
Now that the code is in place for KVM to support MIPS SIMD Architecutre
(MSA) in MIPS guests, wire up the new KVM_CAP_MIPS_MSA capability.
For backwards compatibility, the capability must be explicitly enabled
in order to detect or make use of MSA
On 25/03/2015 16:56, Nate Case wrote:
I was hoping I could then use a PCI sysfs resource file instead of a
tmpfs file (i.e., /sys/bus/pci/devices/:bb:ss.f/resourceN) to
achieve the desired effect. But I haven't been able to get Linux or
memtest86+ to boot with this arrangement. It only
On Thu, 26 Mar 2015 14:39:35 +
Andre Przywara andre.przyw...@arm.com wrote:
Using the framework provided by the recent vgic.c changes we register
a kvm_io_bus device when initializing the virtual GICv2.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
Reviewed-by: Marc Zyngier
On Thu, 26 Mar 2015 14:39:36 +
Andre Przywara andre.przyw...@arm.com wrote:
Currently we handle the redistributor registers in two separate MMIO
regions, one for the overall behaviour and SPIs and one for the
SGIs/PPIs. That latter forces the creation of _two_ KVM I/O bus
devices for each
On Thu, 26 Mar 2015 14:39:37 +
Andre Przywara andre.przyw...@arm.com wrote:
Using the framework provided by the recent vgic.c changes, we
register a kvm_io_bus device on mapping the virtual GICv3 resources.
The distributor mapping is pretty straight forward, but the
redistributors need
2015-03-26 11:47-0700, Andy Lutomirski:
On Wed, Mar 25, 2015 at 4:08 AM, Radim Krčmář rkrc...@redhat.com wrote:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
+ /* A guest can read other VCPU's kvmclock; specification says that
+* version is odd if data is being modified
On Thu, Mar 26, 2015 at 1:31 PM, Radim Krcmar rkrc...@redhat.com wrote:
2015-03-26 11:51-0700, Andy Lutomirski:
On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, Mar 25, 2015 at 04:22:03PM -0700, Andy Lutomirski wrote:
Suppose we start out with all vcpus
On 26/03/2015 21:10, Radim Krčmář wrote:
2015-03-26 11:47-0700, Andy Lutomirski:
On Wed, Mar 25, 2015 at 4:08 AM, Radim Krčmář rkrc...@redhat.com wrote:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
+ /* A guest can read other VCPU's kvmclock; specification says that
+*
2015-03-23 20:21-0300, Marcelo Tosatti:
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
Is not true anymore since KVM: x86: update pvclock area conditionally,
on cpu migration.
Add task migration notification back.
Problem
Radim Krčmář rkrc...@redhat.com writes:
2015-03-26 21:24+0300, Andrey Korolyov:
On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář rkrc...@redhat.com wrote:
2015-03-26 20:08+0300, Andrey Korolyov:
KVM internal error. Suberror: 2
extra data[0]: 80ef
extra data[1]: 8b0d
Btw. does
On Wed, Mar 25, 2015 at 4:08 AM, Radim Krčmář rkrc...@redhat.com wrote:
2015-03-24 15:33-0700, Andy Lutomirski:
On Tue, Mar 24, 2015 at 8:34 AM, Radim Krčmář rkrc...@redhat.com wrote:
What is the problem?
The kvmclock spec says that the host will increment a version field to
an odd number,
On Thu, Mar 26, 2015 at 4:22 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Mar 26, 2015 at 04:09:53PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 3:56 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Mar 26, 2015 at 01:58:25PM -0700, Andy Lutomirski wrote:
On Thu,
On Thu, Mar 26, 2015 at 04:28:37PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 4:22 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Mar 26, 2015 at 04:09:53PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 3:56 PM, Marcelo Tosatti mtosa...@redhat.com
wrote:
On
On Thu, Mar 26, 2015 at 3:56 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Mar 26, 2015 at 01:58:25PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 1:31 PM, Radim Krcmar rkrc...@redhat.com wrote:
2015-03-26 11:51-0700, Andy Lutomirski:
On Thu, Mar 26, 2015 at 4:29 AM,
[much snippage]
On Thu, Mar 26, 2015 at 1:58 PM, Andy Lutomirski l...@amacapital.net wrote:
If the versioning were fixed, I think we could almost get away with:
pvti = pvti for vcpu 0;
ver1 = pvti-version;
check stable bit;
rdtsc_barrier, rdtsc, read scale, shift, etc.
if (pvti-version
On Thu, Mar 26, 2015 at 09:59:24PM +0100, Radim Krčmář wrote:
2015-03-23 20:21-0300, Marcelo Tosatti:
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
Is not true anymore since KVM: x86: update pvclock area conditionally,
on
On Thu, Mar 26, 2015 at 3:22 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Mar 26, 2015 at 09:59:24PM +0100, Radim Krčmář wrote:
2015-03-23 20:21-0300, Marcelo Tosatti:
The following point:
2. per-CPU pvclock time info is updated if the
underlying CPU changes.
On Thu, Mar 26, 2015 at 03:24:10PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 3:22 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Mar 26, 2015 at 09:59:24PM +0100, Radim Krčmář wrote:
2015-03-23 20:21-0300, Marcelo Tosatti:
The following point:
2. per-CPU
On Thu, Mar 26, 2015 at 01:58:25PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 1:31 PM, Radim Krcmar rkrc...@redhat.com wrote:
2015-03-26 11:51-0700, Andy Lutomirski:
On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti mtosa...@redhat.com
wrote:
On Wed, Mar 25, 2015 at 04:22:03PM
On Thu, Mar 26, 2015 at 04:09:53PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 3:56 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Thu, Mar 26, 2015 at 01:58:25PM -0700, Andy Lutomirski wrote:
On Thu, Mar 26, 2015 at 1:31 PM, Radim Krcmar rkrc...@redhat.com wrote:
2015-03-26
On Wed, Mar 25, 2015 at 05:09:13PM +, Marc Zyngier wrote:
On 23/03/15 15:58, Andre Przywara wrote:
In kvm_destroy_vm() we call kvm_io_bus_destroy() pretty early,
especially before calling kvm_arch_destroy_vm(). To avoid
unregistering devices from the already destroyed bus, let's mark
On Mon, Mar 23, 2015 at 07:27:19PM +0100, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
If the guest CPU is supposed to support rdtscp and the host has rdtscp
enabled in the secondary execution controls, we can also expose this
feature to L1. Just extend nested_vmx_exit_handled
Using the framework provided by the recent vgic.c changes, we
register a kvm_io_bus device on mapping the virtual GICv3 resources.
The distributor mapping is pretty straight forward, but the
redistributors need some more love, since they need to be tagged with
the respective redistributor (read:
From: Nikolay Nikolaev n.nikol...@virtualopensystems.com
This is needed in e.g. ARM vGIC emulation, where the MMIO handling
depends on the VCPU that does the access.
Signed-off-by: Nikolay Nikolaev n.nikol...@virtualopensystems.com
Signed-off-by: Andre Przywara andre.przyw...@arm.com
Acked-by:
virt/kvm was never really a good include directory for anything else
than locally included headers.
With the move of iodev.h there is no need anymore to add this
directory the compiler's include path, so remove it from the x86 kvm
Makefile.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
This series converts the VGIC MMIO handling routines to the generic
kvm_io_bus framework. The framework is needed for the ioeventfd
functionality, some people on the list wanted to see the VGIC
converted over to use it, too.
Beside from now moving to a generic framework instead of relying on
an
Currently we use a lot of VGIC specific code to do the MMIO
dispatching.
Use the previous reworks to add kvm_io_bus style MMIO handlers.
Those are not yet called by the MMIO abort handler, also the actual
VGIC emulator function do not make use of it yet, but will be enabled
with the following
The vgic_find_range() function in vgic.c takes a struct kvm_exit_mmio
argument, but actually only used the length field in there. Since we
need to get rid of that structure in that part of the code anyway,
let's rework the function (and it's callers) to pass the length
argument to the function
iodev.h contains definitions for the kvm_io_bus framework. This is
needed both by the generic KVM code in virt/kvm as well as by
architecture specific code under arch/. Putting the header file in
virt/kvm and using local includes in the architecture part seems at
least dodgy to me, so let's move
virt/kvm was never really a good include directory for anything else
than locally included headers.
With the move of iodev.h there is no need anymore to add this
directory the compiler's include path, so remove it from the arm and
arm64 kvm Makefile.
Signed-off-by: Andre Przywara
The name kvm_mmio_range is a bit bold, given that it only covers
the VGIC's MMIO ranges. To avoid confusion with kvm_io_range, rename
it to vgic_io_range.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
Acked-by: Christoffer Dall christoffer.d...@linaro.org
Reviewed-by: Marc Zyngier
Using the framework provided by the recent vgic.c changes we register
a kvm_io_bus device when initializing the virtual GICv2.
Signed-off-by: Andre Przywara andre.przyw...@arm.com
---
include/kvm/arm_vgic.h |1 +
virt/kvm/arm/vgic-v2-emul.c | 22 --
2 files
1 - 100 of 108 matches
Mail list logo
