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
On Thu, Mar 26, 2015 at 5:47 AM, Bandan Das wrote:
> Hi Andrey,
>
> Andrey Korolyov writes:
>
>> On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov wrote:
>>> For now, it looks like bug have a mixed Murphy-Heisenberg nature, as
>>> it appearance is very rare (compared to the number of actual laun
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
---
arch/x86/kvm/vmx.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/
On Wed, Mar 25, 2015 at 04:22:03PM -0700, Andy Lutomirski wrote:
> On Wed, Mar 25, 2015 at 4:13 PM, Marcelo Tosatti 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
> >> wrote:
> >> > On Wed, Mar 25, 2015 at 03:33:1
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
>>> unr
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 bi
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 MS
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 o
Currently we have struct kvm_exit_mmio for encapsulating MMIO abort
data to be passed on from syndrome decoding all the way down to the
VGIC register handlers. Now as we switch the MMIO handling to be
routed through the KVM MMIO bus, it does not make sense anymore to
use that structure already from
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: VC
From: Nikolay Nikolaev
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
Signed-off-by: Andre Przywara
Acked-by: Paolo Bonzini
Acked-by: Christoffer Dall
Reviewed-by: Marc Zyngier
---
arch/powerpc/kv
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
Reviewed-by: Marcelo Tosat
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 ARM
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 patc
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 dire
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 th
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
Acked-by: Christ
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
Acked-by: Christoffer Dall
Reviewed-by: Marc Zyngier
---
virt/kvm/arm/vgic-v2-emul.c |6 +++---
virt/kv
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
---
include/kvm/arm_vgic.h |1 +
virt/kvm/arm/vgic-v2-emul.c | 22 --
2 files changed, 17 insertions(+), 6 d
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 redistributor.
Since the spec mandates those two pages to be contigious, we could as
https://bugzilla.kernel.org/show_bug.cgi?id=93251
--- Comment #10 from Thomas Stein ---
Hello.
I suppose this patch is not included in 3.19.3?
thanks and cheers
t.
--
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line
On 26/03/15 13:58, Paolo Bonzini wrote:
>
>
> 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 explicit
On Thu, Mar 26, 2015 at 12:18 PM, Andrey Korolyov wrote:
> On Thu, Mar 26, 2015 at 5:47 AM, Bandan Das wrote:
>> Hi Andrey,
>>
>> Andrey Korolyov writes:
>>
>>> On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov wrote:
For now, it looks like bug have a mixed Murphy-Heisenberg nature, as
>>>
https://bugzilla.kernel.org/show_bug.cgi?id=93251
--- Comment #11 from Igor Mammedov ---
(In reply to Thomas Stein from comment #10)
> Hello.
>
> I suppose this patch is not included in 3.19.3?
Nope,
I've posted v2 of the patch fixing problems Marcelo pointed out:
https://www.marc.info/?l=kvm&m
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 race (e.g. it is not
> > int19 problem really).
> >
> > object
> > 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 file of the failure, obtain
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 in
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 registers
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 i
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
Cc: Paolo Bonzini
Cc:
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: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 i
> >
> > 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
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
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,
On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor 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 and alway
- 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:
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
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 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=... 19"?
>
>
On Thu, Mar 26, 2015 at 8:06 PM, Kevin O'Connor 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 wrote:
>> > I'm not sure if the crash always happens at the "int $0x19" location
>> > though. Andrey, does the crash always
On 23 March 2015 at 17:05, Alex Bennée 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 not. We then save t
On 23 March 2015 at 17:05, Alex Bennée 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
> Acked-by: Christo
> 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 r
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 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 wrote:
> >> > I'm not sure if the crash always happen
On 23 March 2015 at 17:05, Alex Bennée 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 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 of the aarch64 map
On 23 March 2015 at 17:05, Alex Bennée wrote:
> I was getting very confused about the duplication of state so wanted to
> make it explicit.
>
> Signed-off-by: Alex Bennée
>
> diff --git a/target-arm/cpu.h b/target-arm/cpu.h
> index 083211c..6dc1799 100644
> --- a/target-arm/cpu.h
> +++ b/target-a
On Thu, Mar 26, 2015 at 8:18 PM, Kevin O'Connor 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 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'
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 t
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 gu
On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář 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
> ex
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
On Wed, Mar 25, 2015 at 4:08 AM, Radim Krčmář wrote:
> 2015-03-24 15:33-0700, Andy Lutomirski:
>> On Tue, Mar 24, 2015 at 8:34 AM, Radim Krčmář wrote:
>> > What is the problem?
>>
>> The kvmclock spec says that the host will increment a version field to
>> an odd number, then update stuff, then i
On 26 March 2015 at 19:45, Stefano Stabellini
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
>> > allows userspace
On 26 March 2015 at 19:49, Ard Biesheuvel wrote:
> On 26 March 2015 at 19:45, Stefano Stabellini
> 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 abou
On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti 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 wrote:
>> > On Wed, Mar 25, 2015 at 03:48:02PM -0700, Andy Lutomirski wrote:
>> >> On Wed, Mar 25, 2015 at 3:41 PM, Marcel
2015-03-26 11:47-0700, Andy Lutomirski:
> On Wed, Mar 25, 2015 at 4:08 AM, Radim Krčmář 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 and even af
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 co
2015-03-26 11:51-0700, Andy Lutomirski:
> On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti 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 its frequenc
2015-03-26 21:24+0300, Andrey Korolyov:
> On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář 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 firs
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ář 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
>>> +* versio
On Thu, Mar 26, 2015 at 1:31 PM, Radim Krcmar wrote:
> 2015-03-26 11:51-0700, Andy Lutomirski:
>> On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti 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 perf
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.
>
Radim Krčmář writes:
> 2015-03-26 21:24+0300, Andrey Korolyov:
>> On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář 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
On Thu, 26 Mar 2015 14:39:35 +
Andre Przywara 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
Reviewed-by: Marc Zyngier
M.
--
Jazz is not dead. It just sme
On Thu, 26 Mar 2015 14:39:36 +
Andre Przywara 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 redistributor.
> S
On Thu, 26 Mar 2015 14:39:37 +
Andre Przywara 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 some more love, since
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 cond
[much snippage]
On Thu, Mar 26, 2015 at 1:58 PM, Andy Lutomirski 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 != ver1) r
On Thu, Mar 26, 2015 at 3:22 PM, Marcelo Tosatti 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 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 wrote:
> > 2015-03-26 11:51-0700, Andy Lutomirski:
> >> On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti
> >> wrote:
> >> > On Wed, Mar 25, 2015 at 04:22:03PM -0700, Andy Lutomirski w
On Thu, Mar 26, 2015 at 3:56 PM, Marcelo Tosatti 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 wrote:
>> > 2015-03-26 11:51-0700, Andy Lutomirski:
>> >> On Thu, Mar 26, 2015 at 4:29 AM, Marcelo Tosatti
>> >> 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 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 wrote:
> >> > 2015-03-26 11:51-0700, Andy Lutomirski:
On Thu, Mar 26, 2015 at 4:22 PM, Marcelo Tosatti 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 wrote:
>> > On Thu, Mar 26, 2015 at 01:58:25PM -0700, Andy Lutomirski wrote:
>> >> On Thu, Mar 26, 2015 at 1:31 PM, Radim
On Thu, Mar 26, 2015 at 04:28:37PM -0700, Andy Lutomirski wrote:
> On Thu, Mar 26, 2015 at 4:22 PM, Marcelo Tosatti 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
> >> wrote:
> >> > On Thu, Mar 26, 2015 at 01:58:2
On 03/26/2015 09:53 PM, Marc Zyngier wrote:
> On Thu, 26 Mar 2015 14:39:36 +
> Andre Przywara 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 _t
On 03/26/2015 10:06 PM, Marc Zyngier wrote:
> On Thu, 26 Mar 2015 14:39:37 +
> Andre Przywara 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
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 m
On Mon, Mar 23, 2015 at 07:27:19PM +0100, Jan Kiszka wrote:
> From: Jan Kiszka
>
> 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 to properly route
>
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 th
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 will
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 int
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 thr
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 gu
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: Pau
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 ms
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 thread
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 littl
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. 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 r
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 kvmppc_hv
On Thu, Mar 26, 2015 at 04:42:07PM +1100, Gavin Shan wrote:
> There are two equivalent sets of PE state constants, defined in
> arch/powerpc/include/asm/eeh.h and include/uapi/linux/vfio.h.
> Though the names are different, their corresponding values are
> exactly same. The former is used by EEH co
> -Original Message-
> From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> Sent: Thursday, March 26, 2015 7:18 AM
> To: Wu, Feng; h...@zytor.com
> Cc: t...@linutronix.de; mi...@redhat.com; h...@zytor.com; x...@kernel.org;
> g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
> j..
On 03/16/2015 06:46 PM, Peter Zijlstra wrote:
Hi Waiman,
As promised; here is the paravirt stuff I did during the trip to BOS last week.
All the !paravirt patches are more or less the same as before (the only real
change is the copyright lines in the first patch).
The paravirt stuff is 'simple
98 matches
Mail list logo
