Audio starts working several hours after starting Windows Vista guest

[Dirk Heinrichs]

Hello,

since a week or two, I have a very strange problem with audio output on a 
Windows Vista guest. Right after booting the guest, audio does not work. If I 
leave the guest running for some hours (don't know how many, I usually try 
again next day), audio output works fine.

I'm using es1370 emulation, but I get the same results with the other 
alternatives, too.

Guest: Windows Vista SP1 32bit

Host: Ubuntu 12.10 64bit
% dpkg --list|grep -e kvm -e qemu
ii  kvm-ipxe  1.0.0+git-3.55f6c88-0ubuntu5  
  
all  PXE ROM's for KVM
ii  qemu-common   1.2.0+noroms-0ubuntu2 
  
all  qemu common functionality (bios, documentation, etc)
ii  qemu-kvm  1.2.0+noroms-0ubuntu2 
  
amd64Full virtualization on supported hardware
ii  qemu-kvm-spice1.2.0-2012.09-0ubuntu1
  
amd64Full virtualization on amd64 hardware
ii  qemu-utils1.2.0+noroms-0ubuntu2 
  
amd64qemu utilities

Is this a known problem? What could I do to resolve it?

Thanks...

Dirk
-- 
Dirk Heinrichs dirk.heinri...@altum.de
Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913
GPG Public Key C2E467BB | Jabber: dirk.heinri...@altum.de


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH RFC 1/2] kvm: Handle undercommitted guest case in PLE handler

[Avi Kivity]

On 09/28/2012 08:18 PM, Konrad Rzeszutek Wilk wrote:
  PLE:
  - works for unmodified / non-Linux guests
  - works for all types of spins (e.g. smp_call_function*())
  - utilizes an existing hardware interface (PAUSE instruction) so likely
  more robust compared to a software interface
 
  PV:
  - has more information, so it can perform better
  
  Should we also consider that we always have an edge here for non-PLE
  machine?
 
 True.  The deployment share for these is decreasing rapidly though.  I
 hate optimizing for obsolete hardware.
 
 Keep in mind that the patchset that Jeremy provided also cleans (remove)
 parts of the pv spinlock code. It removes the various spin_lock,
 spin_unlock, etc that touch paravirt code. Instead the pv code is only
 in the slowpath. And if you don't compile with CONFIG_PARAVIRT_SPINLOCK
 the end code is the same as it is now.

We still need to maintain information about the lock holder if pv is
enabled at all, even if it is never used.

 On a different subject-  I am curious whether the Haswell new locking
 instructions (the transactional ones?) can be put in usage for the slow
 case?

Transactions are blown on any context switch, so no.

-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 1/2] kvm: Handle undercommitted guest case in PLE handler

[Avi Kivity]

On 09/28/2012 08:16 AM, Raghavendra K T wrote:
 

 +struct pv_sched_info {
 +   unsigned long   sched_bitmap;
 
 Thinking, whether we need something similar to cpumask here?
 Only thing is we are representing guest (v)cpumask.
 

DECLARE_BITMAP(sched_bitmap, KVM_MAX_VCPUS)

cpumask is for host masks, this is a guest mask.

-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 0/2] kvm: Improving undercommit,overcommit scenarios in PLE handler

[Avi Kivity]

On 09/28/2012 01:40 PM, Andrew Theurer wrote:
 
 
  IIRC, with defer preemption :
  we will have hook in spinlock/unlock path to measure depth of lock held,
  and shared with host scheduler (may be via MSRs now).
  Host scheduler 'prefers' not to preempt lock holding vcpu. (or rather
  give say one chance.
 
  A downside is that we have to do that even when undercommitted.
 
 Hopefully vcpu preemption is very rare when undercommitted, so it should
 not happen much at all.

As soon as you're preempted, you're effectively overcommitted (even if
the system as a whole is undercommitted).  What I meant was that you
need to communicate your lock state to the host, and with fine-grained
locking this can happen a lot.  It may be as simple as an
increment/decrement instruction though.



-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [kvmarm] [PATCH 10/15] KVM: ARM: World-switch implementation

[Peter Maydell]

On 30 September 2012 01:33, Christoffer Dall
c.d...@virtualopensystems.com wrote:
 On Tue, Sep 25, 2012 at 1:42 PM, Marc Zyngier marc.zyng...@arm.com wrote:
 Well, we're still in HYP mode when performing the pop, so the VMID is
 pretty much irrelevant. Same for the initial push, actually. As long as
 we're sure VTTBR has been updated when we do the exception return, I think
 we're safe.

 yeah we're safe, but I can't find anywhere that says the ISB is
 implied from exception handling/hvc, even though I seem to recall
 having read this, so I put this here not to worry other readers.

TLB maintenance operations and the memory order model in section
B3.10.1 of the ARM ARM says that exception entry forces completion of
TLB maintenance ops. Section B5.6.3 (Synchronization of changes to
system control registers) says that taking an exception synchronizes
context, so the VTTBR update is guaranteed to have happened.

-- PMM
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 1/2] kvm: Handle undercommitted guest case in PLE handler

[Gleb Natapov]

On Sun, Sep 30, 2012 at 10:18:17AM +0200, Avi Kivity wrote:
 On 09/28/2012 08:16 AM, Raghavendra K T wrote:
  
 
  +struct pv_sched_info {
  +   unsigned long   sched_bitmap;
  
  Thinking, whether we need something similar to cpumask here?
  Only thing is we are representing guest (v)cpumask.
  
 
 DECLARE_BITMAP(sched_bitmap, KVM_MAX_VCPUS)
 
vcpu_id can be greater than KVM_MAX_VCPUS.

 cpumask is for host masks, this is a guest mask.
 
 -- 
 error compiling committee.c: too many arguments to function

--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=10002 jiffies)

[Avi Kivity]

On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
 On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
 On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
  On Thu, Sep 27, 2012 at 10:54:00AM +0800, Fengguang Wu wrote:
   On Wed, Sep 26, 2012 at 09:45:43AM -0700, Paul E. McKenney wrote:
On Wed, Sep 26, 2012 at 04:15:01PM +0800, Fengguang Wu wrote:
 
 [ . . . ]
 
But could you also please send your .config file and a description of
   
   .config attached.
   
the workload you are running?
   
   It's basically the below commands. The exact initrd is not relevant in
   this case because it's a boot time warning before user space is
   started. The stalls roughly happen 1 time on every 10 boots.
  
  Yow!!!
  
  You have severe cross-CPU time-synchronization problems.  See for
  example the first dmesg, with the relevant part extracted right here.
  One CPU believes that it is about 37 seconds past boot, and the other
  CPU beleives that it is about 137 seconds past boot.  Given that large
  of a time difference, an RCU CPU stall warning is expected behavior.
 
 Good spot! Yeah I noticed that huge timestamp gap, however didn't take
 it seriously enough..
 
  Get your two CPUs in agreement about what time it is, and I bet that
  the CPU stall warnings will go away.
 
 Possibly KVM related? Because the warnings show up in many test boxes
 running KVM and so is not likely some hardware specific issue.
 
 I vaguely recall seeing something recently.  But let's ask the KVM and
 timekeeping guys.

From the logs it looks like hpet (why not kvmclock?) is used for the
clock, it should not generate such drifts since it is a global clock.
Can you verify current_clocksource on a boot that actually failed (in
case the clocksource is switched during runtime)?


-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RFC 1/2] kvm: Handle undercommitted guest case in PLE handler

[Avi Kivity]

On 09/30/2012 01:07 PM, Gleb Natapov wrote:
 On Sun, Sep 30, 2012 at 10:18:17AM +0200, Avi Kivity wrote:
 On 09/28/2012 08:16 AM, Raghavendra K T wrote:
  
 
  +struct pv_sched_info {
  +   unsigned long   sched_bitmap;
  
  Thinking, whether we need something similar to cpumask here?
  Only thing is we are representing guest (v)cpumask.
  
 
 DECLARE_BITMAP(sched_bitmap, KVM_MAX_VCPUS)
 
 vcpu_id can be greater than KVM_MAX_VCPUS.

Use the index into the vcpu table as the bitmap index then.  In fact
it's better because then the lookup to get the vcpu pointer is trivial.


-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=10002 jiffies)

[Fengguang Wu]

On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote:
 On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
  On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
  On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
   On Thu, Sep 27, 2012 at 10:54:00AM +0800, Fengguang Wu wrote:
On Wed, Sep 26, 2012 at 09:45:43AM -0700, Paul E. McKenney wrote:
 On Wed, Sep 26, 2012 at 04:15:01PM +0800, Fengguang Wu wrote:
  
  [ . . . ]
  
 But could you also please send your .config file and a description of

.config attached.

 the workload you are running?

It's basically the below commands. The exact initrd is not relevant in
this case because it's a boot time warning before user space is
started. The stalls roughly happen 1 time on every 10 boots.
   
   Yow!!!
   
   You have severe cross-CPU time-synchronization problems.  See for
   example the first dmesg, with the relevant part extracted right here.
   One CPU believes that it is about 37 seconds past boot, and the other
   CPU beleives that it is about 137 seconds past boot.  Given that large
   of a time difference, an RCU CPU stall warning is expected behavior.
  
  Good spot! Yeah I noticed that huge timestamp gap, however didn't take
  it seriously enough..
  
   Get your two CPUs in agreement about what time it is, and I bet that
   the CPU stall warnings will go away.
  
  Possibly KVM related? Because the warnings show up in many test boxes
  running KVM and so is not likely some hardware specific issue.
  
  I vaguely recall seeing something recently.  But let's ask the KVM and
  timekeeping guys.
 
 From the logs it looks like hpet (why not kvmclock?) is used for the

Hi Avi! Thanks for looking into this. It seems you have the full logs
attached in my previous email?

FYI, I've enabled CONFIG_KVM_CLOCK/CONFIG_KVM_GUEST for all bootable
kernels and here is the related boot message:

[0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
[0.00] kvm-clock: cpu 0, msr 0:1b7ec81, boot clock

 clock, it should not generate such drifts since it is a global clock.
 Can you verify current_clocksource on a boot that actually failed (in
 case the clocksource is switched during runtime)?

I see a line

[2.011710] Switching to clocksource kvm-clock

w/o any indication of errors.

Thanks,
Fengguang
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] KVM: PPC: e500: fix allocation size error on g2h_tlb1_map

[Avi Kivity]

On 09/27/2012 09:59 PM, Alexander Graf wrote:
 
 Do you have the auto-autotest setup ready?  I guess we can do it
 manually until it is.
 
 I do have a local autotest setup. Or what exactly are you referring to?

Getting autotest to run automatically and produce readable reports, and
auto-bisection.

-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=10002 jiffies)

[Avi Kivity]

On 09/30/2012 01:18 PM, Fengguang Wu wrote:
 On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote:
 On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
  On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
  On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
   On Thu, Sep 27, 2012 at 10:54:00AM +0800, Fengguang Wu wrote:
On Wed, Sep 26, 2012 at 09:45:43AM -0700, Paul E. McKenney wrote:
 On Wed, Sep 26, 2012 at 04:15:01PM +0800, Fengguang Wu wrote:
  
  [ . . . ]
  
 But could you also please send your .config file and a description 
 of

.config attached.

 the workload you are running?

It's basically the below commands. The exact initrd is not relevant in
this case because it's a boot time warning before user space is
started. The stalls roughly happen 1 time on every 10 boots.
   
   Yow!!!
   
   You have severe cross-CPU time-synchronization problems.  See for
   example the first dmesg, with the relevant part extracted right here.
   One CPU believes that it is about 37 seconds past boot, and the other
   CPU beleives that it is about 137 seconds past boot.  Given that large
   of a time difference, an RCU CPU stall warning is expected behavior.
  
  Good spot! Yeah I noticed that huge timestamp gap, however didn't take
  it seriously enough..
  
   Get your two CPUs in agreement about what time it is, and I bet that
   the CPU stall warnings will go away.
  
  Possibly KVM related? Because the warnings show up in many test boxes
  running KVM and so is not likely some hardware specific issue.
  
  I vaguely recall seeing something recently.  But let's ask the KVM and
  timekeeping guys.
 
 From the logs it looks like hpet (why not kvmclock?) is used for the
 
 Hi Avi! Thanks for looking into this. It seems you have the full logs
 attached in my previous email?
 
 FYI, I've enabled CONFIG_KVM_CLOCK/CONFIG_KVM_GUEST for all bootable
 kernels and here is the related boot message:
 
 [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
 [0.00] kvm-clock: cpu 0, msr 0:1b7ec81, boot clock
 
 clock, it should not generate such drifts since it is a global clock.
 Can you verify current_clocksource on a boot that actually failed (in
 case the clocksource is switched during runtime)?
 
 I see a line
 
 [2.011710] Switching to clocksource kvm-clock
 
 w/o any indication of errors.

So, with kvmclock it works and with hpet it fails?  Strange, hpet is
simple while kvmclock is more complicated, I'd have expected the
opposite behaviour.



-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=10002 jiffies)

[Avi Kivity]

On 09/30/2012 01:23 PM, Fengguang Wu wrote:
 On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote:
 On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
  On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
  On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
   On Thu, Sep 27, 2012 at 10:54:00AM +0800, Fengguang Wu wrote:
On Wed, Sep 26, 2012 at 09:45:43AM -0700, Paul E. McKenney wrote:
 On Wed, Sep 26, 2012 at 04:15:01PM +0800, Fengguang Wu wrote:
  
  [ . . . ]
  
 But could you also please send your .config file and a description 
 of

.config attached.

 the workload you are running?

It's basically the below commands. The exact initrd is not relevant in
this case because it's a boot time warning before user space is
started. The stalls roughly happen 1 time on every 10 boots.
   
   Yow!!!
   
   You have severe cross-CPU time-synchronization problems.  See for
   example the first dmesg, with the relevant part extracted right here.
   One CPU believes that it is about 37 seconds past boot, and the other
   CPU beleives that it is about 137 seconds past boot.  Given that large
   of a time difference, an RCU CPU stall warning is expected behavior.
  
  Good spot! Yeah I noticed that huge timestamp gap, however didn't take
  it seriously enough..
  
   Get your two CPUs in agreement about what time it is, and I bet that
   the CPU stall warnings will go away.
  
  Possibly KVM related? Because the warnings show up in many test boxes
  running KVM and so is not likely some hardware specific issue.
  
  I vaguely recall seeing something recently.  But let's ask the KVM and
  timekeeping guys.
 
 From the logs it looks like hpet (why not kvmclock?) is used for the
 clock, it should not generate such drifts since it is a global clock.
 Can you verify current_clocksource on a boot that actually failed (in
 case the clocksource is switched during runtime)?
 
 I've checked out the dmesg that's cited by Paul, attached. Yes it
 contains lines
 
 [4.970051] Switching to clocksource hpet
 
 and then
 
 [7.250353] Switching to clocksource tsc
 
 And there is no kvm-clock lines. Oh well for this particular kernel:
 

Ah, tsc will certainly break on kvm if the hardware doesn't provide a
constant tsc source.  I'm surprised the guest kernel didn't detect it
and switch back to hpet though.


-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=10002 jiffies)

[Fengguang Wu]

On Sun, Sep 30, 2012 at 01:32:46PM +0200, Avi Kivity wrote:
 On 09/30/2012 01:23 PM, Fengguang Wu wrote:
  On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote:
  On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
   On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
   On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
On Thu, Sep 27, 2012 at 10:54:00AM +0800, Fengguang Wu wrote:
 On Wed, Sep 26, 2012 at 09:45:43AM -0700, Paul E. McKenney wrote:
  On Wed, Sep 26, 2012 at 04:15:01PM +0800, Fengguang Wu wrote:
   
   [ . . . ]
   
  But could you also please send your .config file and a 
  description of
 
 .config attached.
 
  the workload you are running?
 
 It's basically the below commands. The exact initrd is not relevant 
 in
 this case because it's a boot time warning before user space is
 started. The stalls roughly happen 1 time on every 10 boots.

Yow!!!

You have severe cross-CPU time-synchronization problems.  See for
example the first dmesg, with the relevant part extracted right here.
One CPU believes that it is about 37 seconds past boot, and the other
CPU beleives that it is about 137 seconds past boot.  Given that large
of a time difference, an RCU CPU stall warning is expected behavior.
   
   Good spot! Yeah I noticed that huge timestamp gap, however didn't take
   it seriously enough..
   
Get your two CPUs in agreement about what time it is, and I bet that
the CPU stall warnings will go away.
   
   Possibly KVM related? Because the warnings show up in many test boxes
   running KVM and so is not likely some hardware specific issue.
   
   I vaguely recall seeing something recently.  But let's ask the KVM and
   timekeeping guys.
  
  From the logs it looks like hpet (why not kvmclock?) is used for the
  clock, it should not generate such drifts since it is a global clock.
  Can you verify current_clocksource on a boot that actually failed (in
  case the clocksource is switched during runtime)?
  
  I've checked out the dmesg that's cited by Paul, attached. Yes it
  contains lines
  
  [4.970051] Switching to clocksource hpet
  
  and then
  
  [7.250353] Switching to clocksource tsc
  
  And there is no kvm-clock lines. Oh well for this particular kernel:
  
 
 Ah, tsc will certainly break on kvm if the hardware doesn't provide a
 constant tsc source.  I'm surprised the guest kernel didn't detect it
 and switch back to hpet though.

Thanks, it's good to know the root cause. All the dmesgs show the same hpet+tsc
switching pattern (and never switch back):

$ grep Switching dmesg-kvm_bisect2-inn-*21
dmesg-kvm_bisect2-inn-41931-2012-09-27-10-37-51-3.6.0-rc7-bisect2-00078-g593d100-21:[
4.111415] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-41931-2012-09-27-10-37-51-3.6.0-rc7-bisect2-00078-g593d100-21:[
6.550098] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-41931-2012-09-27-10-41-48-3.6.0-rc7-bisect2-00078-g593d100-21:[
3.927716] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-41931-2012-09-27-10-41-48-3.6.0-rc7-bisect2-00078-g593d100-21:[
6.030117] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-35-17-3.6.0-rc7-bisect2-00078-g593d100-21:[
3.587408] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-35-17-3.6.0-rc7-bisect2-00078-g593d100-21:[
5.812400] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-43-56-3.6.0-rc7-bisect2-00078-g593d100-21:[
4.294842] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-43-56-3.6.0-rc7-bisect2-00078-g593d100-21:[
6.491696] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-47-03-3.6.0-rc7-bisect2-00078-g593d100-21:[
4.745749] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-47-03-3.6.0-rc7-bisect2-00078-g593d100-21:[
7.193121] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-42527-2012-09-27-10-38-38-3.6.0-rc7-bisect2-00078-g593d100-21:[
4.970051] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-42527-2012-09-27-10-38-38-3.6.0-rc7-bisect2-00078-g593d100-21:[
7.250353] Switching to clocksource tsc

And these are the stall times:

$ grep -hC1 stalls dmesg-kvm_bisect2-inn-*21
[   36.122624] bus: 'platform': really_probe: probing driver i8042 with device 
i8042
[   36.106893] INFO: rcu_preempt self-detected stall on CPU[  210.200388] INFO: 
rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=17413 jiffies)
[  210.200417] Pid: 0, comm: swapper/0 Not tainted 
3.6.0-rc7-bisect2-00078-g593d100 #21
--
[   35.403888] bus: 'platform': really_probe: probing driver i8042 with device 
i8042
[  212.130131] INFO: rcu_preempt detected stalls on CPUs/tasks:[  212.131029] 
rcu-torture: rtc: c1a5e988 ver: 228 tfle: 0 rta: 228 rtaf: 162 rtf: 206 rtmbe: 
0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 988 onoff: 0/0:0/0 -1,0:-1,0 0:0 

Re: [PATCH 09/15] KVM: ARM: Inject IRQs and FIQs from userspace

[Will Deacon]

Hi Christoffer,

On Sat, Sep 29, 2012 at 04:50:25PM +0100, Christoffer Dall wrote:
 On Tue, Sep 25, 2012 at 11:55 AM, Will Deacon will.dea...@arm.com wrote:
  On Sat, Sep 15, 2012 at 04:35:27PM +0100, Christoffer Dall wrote:
  diff --git a/arch/arm/include/asm/kvm.h b/arch/arm/include/asm/kvm.h
  index a13b582..131e632 100644
  --- a/arch/arm/include/asm/kvm.h
  +++ b/arch/arm/include/asm/kvm.h
  @@ -22,6 +22,7 @@
   #include asm/types.h
 
   #define __KVM_HAVE_GUEST_DEBUG
  +#define __KVM_HAVE_IRQ_LINE
 
   #define KVM_REG_SIZE(id) \
(1U  (((id)  KVM_REG_SIZE_MASK)  KVM_REG_SIZE_SHIFT))
  @@ -85,4 +86,24 @@ struct kvm_reg_list {
   #define KVM_REG_ARM_CORE (0x0010  KVM_REG_ARM_COPROC_SHIFT)
   #define KVM_REG_ARM_CORE_REG(name)   (offsetof(struct kvm_regs, name) / 4)
 
  +/* KVM_IRQ_LINE irq field index values */
  +#define KVM_ARM_IRQ_TYPE_SHIFT   24
  +#define KVM_ARM_IRQ_TYPE_MASK0xff
  +#define KVM_ARM_IRQ_VCPU_SHIFT   16
  +#define KVM_ARM_IRQ_VCPU_MASK0xff
  +#define KVM_ARM_IRQ_NUM_SHIFT0
  +#define KVM_ARM_IRQ_NUM_MASK 0x
  +
  +/* irq_type field */
  +#define KVM_ARM_IRQ_TYPE_CPU 0
  +#define KVM_ARM_IRQ_TYPE_SPI 1
  +#define KVM_ARM_IRQ_TYPE_PPI 2
  +
  +/* out-of-kernel GIC cpu interrupt injection irq_number field */
  +#define KVM_ARM_IRQ_CPU_IRQ  0
  +#define KVM_ARM_IRQ_CPU_FIQ  1
  +
  +/* Highest supported SPI, from VGIC_NR_IRQS */
  +#define KVM_ARM_IRQ_GIC_MAX  127
 
  This define, and those referring to PPIs and SPIs sound highly GIC-specific.
  Is that really appropriate for kvm.h? Do you mandate a single GIC as the
  only interrupt controller?
 
 
 you can add a another gic with another in-kernel gic emulation if
 someone makes such one that's different from the vgic specifications
 by defining another irq type.
 
 devices must interact with a gic available in the kernel, so I think
 referring to PPIs and SPIs is very appropriate in kvm.h for a user
 space device emulation that must inject either a PPI or an SPI.
 
 We can call them TYPE_GIC_V2_XXX or something like that if you feel
 this is cleaner.

It's more that the GIC isn't really part of the architecture, so it would be
cleaner to have the GIC-specifics separated out from the architectural part
of KVM. That will also make it easier when adding support for future
versions of the GIC.

If core KVM needs the concept of a per-cpu interrupt, just call it
IRQ_TYPE_PERCPU or something rather than PPI.

Will
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [kvmarm] [PATCH 10/15] KVM: ARM: World-switch implementation

[Christoffer Dall]

On Sun, Sep 30, 2012 at 5:48 AM, Peter Maydell peter.mayd...@linaro.org wrote:
 On 30 September 2012 01:33, Christoffer Dall
 c.d...@virtualopensystems.com wrote:
 On Tue, Sep 25, 2012 at 1:42 PM, Marc Zyngier marc.zyng...@arm.com wrote:
 Well, we're still in HYP mode when performing the pop, so the VMID is
 pretty much irrelevant. Same for the initial push, actually. As long as
 we're sure VTTBR has been updated when we do the exception return, I think
 we're safe.

 yeah we're safe, but I can't find anywhere that says the ISB is
 implied from exception handling/hvc, even though I seem to recall
 having read this, so I put this here not to worry other readers.

 TLB maintenance operations and the memory order model in section
 B3.10.1 of the ARM ARM says that exception entry forces completion of
 TLB maintenance ops. Section B5.6.3 (Synchronization of changes to
 system control registers) says that taking an exception synchronizes
 context, so the VTTBR update is guaranteed to have happened.

thanks - I was counting on your help here :)

-Christoffer
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/15] KVM: ARM: Inject IRQs and FIQs from userspace

[Christoffer Dall]

On Sun, Sep 30, 2012 at 8:48 AM, Will Deacon will.dea...@arm.com wrote:
 Hi Christoffer,

 On Sat, Sep 29, 2012 at 04:50:25PM +0100, Christoffer Dall wrote:
 On Tue, Sep 25, 2012 at 11:55 AM, Will Deacon will.dea...@arm.com wrote:
  On Sat, Sep 15, 2012 at 04:35:27PM +0100, Christoffer Dall wrote:
  diff --git a/arch/arm/include/asm/kvm.h b/arch/arm/include/asm/kvm.h
  index a13b582..131e632 100644
  --- a/arch/arm/include/asm/kvm.h
  +++ b/arch/arm/include/asm/kvm.h
  @@ -22,6 +22,7 @@
   #include asm/types.h
 
   #define __KVM_HAVE_GUEST_DEBUG
  +#define __KVM_HAVE_IRQ_LINE
 
   #define KVM_REG_SIZE(id) \
(1U  (((id)  KVM_REG_SIZE_MASK)  KVM_REG_SIZE_SHIFT))
  @@ -85,4 +86,24 @@ struct kvm_reg_list {
   #define KVM_REG_ARM_CORE (0x0010  KVM_REG_ARM_COPROC_SHIFT)
   #define KVM_REG_ARM_CORE_REG(name)   (offsetof(struct kvm_regs, name) / 
  4)
 
  +/* KVM_IRQ_LINE irq field index values */
  +#define KVM_ARM_IRQ_TYPE_SHIFT   24
  +#define KVM_ARM_IRQ_TYPE_MASK0xff
  +#define KVM_ARM_IRQ_VCPU_SHIFT   16
  +#define KVM_ARM_IRQ_VCPU_MASK0xff
  +#define KVM_ARM_IRQ_NUM_SHIFT0
  +#define KVM_ARM_IRQ_NUM_MASK 0x
  +
  +/* irq_type field */
  +#define KVM_ARM_IRQ_TYPE_CPU 0
  +#define KVM_ARM_IRQ_TYPE_SPI 1
  +#define KVM_ARM_IRQ_TYPE_PPI 2
  +
  +/* out-of-kernel GIC cpu interrupt injection irq_number field */
  +#define KVM_ARM_IRQ_CPU_IRQ  0
  +#define KVM_ARM_IRQ_CPU_FIQ  1
  +
  +/* Highest supported SPI, from VGIC_NR_IRQS */
  +#define KVM_ARM_IRQ_GIC_MAX  127
 
  This define, and those referring to PPIs and SPIs sound highly 
  GIC-specific.
  Is that really appropriate for kvm.h? Do you mandate a single GIC as the
  only interrupt controller?
 

 you can add a another gic with another in-kernel gic emulation if
 someone makes such one that's different from the vgic specifications
 by defining another irq type.

 devices must interact with a gic available in the kernel, so I think
 referring to PPIs and SPIs is very appropriate in kvm.h for a user
 space device emulation that must inject either a PPI or an SPI.

 We can call them TYPE_GIC_V2_XXX or something like that if you feel
 this is cleaner.

 It's more that the GIC isn't really part of the architecture, so it would be
 cleaner to have the GIC-specifics separated out from the architectural part
 of KVM. That will also make it easier when adding support for future
 versions of the GIC.

 If core KVM needs the concept of a per-cpu interrupt, just call it
 IRQ_TYPE_PERCPU or something rather than PPI.

that we have already, KVM_ARM_IRQ_TYPE_CPU

then how do you propose an interface for a user space emulation of a
board that uses the vgic where a device needs to inject a PPI to the
kernel that emulates the vgic?

I don't see the dire need for this separation: the API is extendable
and covers all the needs at this point.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/15] KVM: ARM: World-switch implementation

[Christoffer Dall]

On Tue, Sep 25, 2012 at 1:00 PM, Will Deacon will.dea...@arm.com wrote:
 On Sat, Sep 15, 2012 at 04:35:33PM +0100, Christoffer Dall wrote:
 diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
 index 1429d89..cd8fc86 100644
 --- a/arch/arm/kernel/asm-offsets.c
 +++ b/arch/arm/kernel/asm-offsets.c
 @@ -13,6 +13,7 @@
  #include linux/sched.h
  #include linux/mm.h
  #include linux/dma-mapping.h
 +#include linux/kvm_host.h
  #include asm/cacheflush.h
  #include asm/glue-df.h
  #include asm/glue-pf.h
 @@ -144,5 +145,48 @@ int main(void)
DEFINE(DMA_BIDIRECTIONAL,DMA_BIDIRECTIONAL);
DEFINE(DMA_TO_DEVICE,DMA_TO_DEVICE);
DEFINE(DMA_FROM_DEVICE,  DMA_FROM_DEVICE);
 +#ifdef CONFIG_KVM_ARM_HOST
 +  DEFINE(VCPU_KVM, offsetof(struct kvm_vcpu, kvm));
 +  DEFINE(VCPU_MIDR,offsetof(struct kvm_vcpu, arch.midr));
 +  DEFINE(VCPU_MPIDR,   offsetof(struct kvm_vcpu, 
 arch.cp15[c0_MPIDR]));
 +  DEFINE(VCPU_CSSELR,  offsetof(struct kvm_vcpu, 
 arch.cp15[c0_CSSELR]));
 +  DEFINE(VCPU_SCTLR,   offsetof(struct kvm_vcpu, 
 arch.cp15[c1_SCTLR]));
 +  DEFINE(VCPU_CPACR,   offsetof(struct kvm_vcpu, 
 arch.cp15[c1_CPACR]));
 +  DEFINE(VCPU_TTBR0,   offsetof(struct kvm_vcpu, 
 arch.cp15[c2_TTBR0]));
 +  DEFINE(VCPU_TTBR1,   offsetof(struct kvm_vcpu, 
 arch.cp15[c2_TTBR1]));
 +  DEFINE(VCPU_TTBCR,   offsetof(struct kvm_vcpu, 
 arch.cp15[c2_TTBCR]));
 +  DEFINE(VCPU_DACR,offsetof(struct kvm_vcpu, 
 arch.cp15[c3_DACR]));
 +  DEFINE(VCPU_DFSR,offsetof(struct kvm_vcpu, 
 arch.cp15[c5_DFSR]));
 +  DEFINE(VCPU_IFSR,offsetof(struct kvm_vcpu, 
 arch.cp15[c5_IFSR]));
 +  DEFINE(VCPU_ADFSR,   offsetof(struct kvm_vcpu, 
 arch.cp15[c5_ADFSR]));
 +  DEFINE(VCPU_AIFSR,   offsetof(struct kvm_vcpu, 
 arch.cp15[c5_AIFSR]));
 +  DEFINE(VCPU_DFAR,offsetof(struct kvm_vcpu, 
 arch.cp15[c6_DFAR]));
 +  DEFINE(VCPU_IFAR,offsetof(struct kvm_vcpu, 
 arch.cp15[c6_IFAR]));
 +  DEFINE(VCPU_PRRR,offsetof(struct kvm_vcpu, 
 arch.cp15[c10_PRRR]));
 +  DEFINE(VCPU_NMRR,offsetof(struct kvm_vcpu, 
 arch.cp15[c10_NMRR]));
 +  DEFINE(VCPU_VBAR,offsetof(struct kvm_vcpu, 
 arch.cp15[c12_VBAR]));
 +  DEFINE(VCPU_CID, offsetof(struct kvm_vcpu, 
 arch.cp15[c13_CID]));
 +  DEFINE(VCPU_TID_URW, offsetof(struct kvm_vcpu, 
 arch.cp15[c13_TID_URW]));
 +  DEFINE(VCPU_TID_URO, offsetof(struct kvm_vcpu, 
 arch.cp15[c13_TID_URO]));
 +  DEFINE(VCPU_TID_PRIV,offsetof(struct kvm_vcpu, 
 arch.cp15[c13_TID_PRIV]));

 Could you instead define an offset for arch.cp15, then use scaled offsets
 from that in the assembly code?


that would require changing the enum in kvm_host.h to defines and
either wrap that whole file in #ifndef __ASSEMBLY__ or move those
defines to kvm_asm.h, not sure which I think is the most pretty:

diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index 5315c69..99c0faf 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -19,6 +19,34 @@
 #ifndef __ARM_KVM_ASM_H__
 #define __ARM_KVM_ASM_H__

+/* 0 is reserved as an invalid value. */
+#define c0_MPIDR   1   /* MultiProcessor ID Register */
+#define c0_CSSELR  2   /* Cache Size Selection Register */
+#define c1_SCTLR   3   /* System Control Register */
+#define c1_ACTLR   4   /* Auxilliary Control Register */
+#define c1_CPACR   5   /* Coprocessor Access Control */
+#define c2_TTBR0   6   /* Translation Table Base Register 0 */
+#define c2_TTBR0_high  7   /* TTBR0 top 32 bits */
+#define c2_TTBR1   8   /* Translation Table Base Register 1 */
+#define c2_TTBR1_high  9   /* TTBR1 top 32 bits */
+#define c2_TTBCR   10  /* Translation Table Base Control R. */
+#define c3_DACR11  /* Domain Access Control Register */
+#define c5_DFSR12  /* Data Fault Status Register */
+#define c5_IFSR13  /* Instruction Fault Status Register */
+#define c5_ADFSR   14  /* Auxilary Data Fault Status R */
+#define c5_AIFSR   15  /* Auxilary Instrunction Fault Status R */
+#define c6_DFAR16  /* Data Fault Address Register */
+#define c6_IFAR17  /* Instruction Fault Address Register */
+#define c9_L2CTLR  18  /* Cortex A15 L2 Control Register */
+#define c10_PRRR   19  /* Primary Region Remap Register */
+#define c10_NMRR   20  /* Normal Memory Remap Register */
+#define c12_VBAR   21  /* Vector Base Address Register */
+#define c13_CID22  /* Context ID Register */
+#define c13_TID_URW23  /* Thread ID, User R/W */
+#define c13_TID_URO24  /* Thread ID, User R/O */
+#define c13_TID_PRIV   25  /* Thread ID, Priveleged */
+#define NR_CP15_REGS   26  

Re: [PATCH 06/15] KVM: ARM: Initial skeleton to compile KVM support

[Christoffer Dall]

On Thu, Sep 27, 2012 at 10:13 AM, Will Deacon will.dea...@arm.com wrote:
 On Wed, Sep 26, 2012 at 02:43:14AM +0100, Christoffer Dall wrote:
 On 09/25/2012 11:20 AM, Will Deacon wrote:
  +/* Multiprocessor Affinity Register */
  +#define MPIDR_CPUID(0x3  0)
 
  I'm fairly sure we already have code under arch/arm/ for dealing with the
  mpidr. Let's re-use that rather than reinventing it here.
 

 I see some defines in topology.c - do you want some of these factored
 out into a header file that we can then also use from kvm? If so, where?

 I guess either in topology.h or a new header (topology-bits.h).

  +#define EXCEPTION_NONE  0
  +#define EXCEPTION_RESET 0x80
  +#define EXCEPTION_UNDEFINED 0x40
  +#define EXCEPTION_SOFTWARE  0x20
  +#define EXCEPTION_PREFETCH  0x10
  +#define EXCEPTION_DATA  0x08
  +#define EXCEPTION_IMPRECISE 0x04
  +#define EXCEPTION_IRQ   0x02
  +#define EXCEPTION_FIQ   0x01
 
  Why the noise?
 

 these are simply cruft from a previous life of KVM/ARM.

 Ok, then please get rid of them.

  +static inline enum vcpu_mode vcpu_mode(struct kvm_vcpu *vcpu)
  +{
  +   u8 mode = __vcpu_mode(vcpu-arch.regs.cpsr);
  +   BUG_ON(mode == 0xf);
  +   return mode;
  +}
 
  I noticed that you have a fair few BUG_ONs throughout the series. Fair
  enough, but for hyp code is that really the right thing to do? Killing the
  guest could make more sense, perhaps?

 the idea is to have BUG_ONs that are indeed BUG_ONs that we want to
 catch explicitly on the host. We have had a pass over the code to change
 all the BUG_ONs that can be provoked by the guest and inject the proper
 exceptions into the guest in this case. If you find places where this is
 not the case, it should be changed, and do let me know.

 Ok, so are you saying that a BUG_ON due to some detected inconsistency with
 one guest may not necessarily terminate the other guests? BUG_ONs in the
 host seem like a bad idea if the host is able to continue with a subset of
 guests.


No, I'm saying a BUG_ON is an actual BUG, it should not happen and
there should be nowhere where a guest can cause a BUG_ON to occur in
the host, because that would be a bug.

We basically never kill a guest unless really extreme things happen
(like we cannot allocate a pte, in which case we return -ENOMEM). If a
guest does something really weird, that guest will receive the
appropriate exception (undefined, prefetch abort, ...)

 
  +static inline u32 *vcpu_pc(struct kvm_vcpu *vcpu)
  +{
  +   return vcpu_reg(vcpu, 15);
  +}
 
  If you stick a struct pt_regs into struct kvm_regs, you could reuse ARM_pc
  here etc.
 

 I prefer not to, because we'd have those registers presumably for usr
 mode and then we only define the others explicit. I think it's much
 clearer to look at kvm_regs today.

 I disagree and think that you should reuse as much of the arch/arm/ code as
 possible. Not only does it make it easier to read by people who are familiar
 with that code (and in turn get you more reviewers) but it also means that
 we limit the amount of duplication that we have.

Reusing a struct just for the sake of reusing is not necessarily an
improvement. Some times it complicates things, and some times it's
misleading. To me, pt_regs carry the meaning that these are the
registers for a user space process that traps into the kernel - in KVM
we emulate a virtual CPU and that current definition is quite clear.

The argument that more people will review the code if the struct
contains a pt_regs field rather than a usr_regs field is completely
invalid, because I'm sure everyone that reviews virtualization code
will know that user mode is a mode on the cpu and it has some
registers and this is the state we store when we context switch a VM -
pt_regs could be read as the regs that we stored in the mode that the
VM happened to be in when we took an exception, which I would think is
crazy, and probably not what you suggest.

Writing the literal 15 for the PC register is not really a problem in
terms of duplication - it's nothing that requires separate
maintenance.

At this point the priority should really be correctness, readability,
and performance, imho.


 I think Marc (CC'd) had a go at this with some success.


great, if this improves the code, then I suggest someone rebases an
appropriate patch and sends it to the kvmarm mailing list so we can
have a look at it, but there are users out there looking to try
kvm/arm and we should try to give it to them.

  +#ifndef __ARM_KVM_HOST_H__
  +#define __ARM_KVM_HOST_H__
  +
  +#include asm/kvm.h
  +
  +#define KVM_MAX_VCPUS 4
 
  NR_CPUS?
 

 well this is defined by KVM generic code, and is common for other
 architecture.

 I mean #define KVM_MAX_CPUS NR_CPUS. The 4 seems arbitrary.

  +int __attribute_const__ kvm_target_cpu(void)
  +{
  +   unsigned int midr;
  +
  +   midr = read_cpuid_id();
  +   switch ((midr  4)  0xfff) {
  +   case KVM_ARM_TARGET_CORTEX_A15:
  +   

qemu-kvm: remove boot=on|off drive parameter compatibility

[Marcelo Tosatti]

Option is deprecated and warning has been in place for one year.

Signed-off-by: Marcelo Tosatti mtosa...@redhat.com

diff --git a/blockdev.c b/blockdev.c
index 4a5266e..7c83baa 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -432,12 +432,6 @@ DriveInfo *drive_init(QemuOpts *opts, int default_to_scsi)
 return NULL;
 }
 
-if (qemu_opt_get(opts, boot) != NULL) {
-fprintf(stderr, qemu-kvm: boot=on|off is deprecated and will be 
-ignored. Future versions will reject this parameter. Please 
-update your scripts.\n);
-}
-
 on_write_error = BLOCK_ERR_STOP_ENOSPC;
 if ((buf = qemu_opt_get(opts, werror)) != NULL) {
 if (type != IF_IDE  type != IF_SCSI  type != IF_VIRTIO  type != 
IF_NONE) {
diff --git a/qemu-config.c b/qemu-config.c
index 3eaee48..eba977e 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -114,10 +114,6 @@ static QemuOptsList qemu_drive_opts = {
 .name = copy-on-read,
 .type = QEMU_OPT_BOOL,
 .help = copy read data from backing file into image file,
-},{
-.name = boot,
-.type = QEMU_OPT_BOOL,
-.help = (deprecated, ignored),
 },
 { /* end of list */ }
 },

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 14/15] KVM: ARM: Handle I/O aborts

[Christoffer Dall]

On Thu, Sep 27, 2012 at 11:11 AM, Will Deacon will.dea...@arm.com wrote:
 On Sat, Sep 15, 2012 at 04:35:59PM +0100, Christoffer Dall wrote:
 When the guest accesses I/O memory this will create data abort
 exceptions and they are handled by decoding the HSR information
 (physical address, read/write, length, register) and forwarding reads
 and writes to QEMU which performs the device emulation.

 Certain classes of load/store operations do not support the syndrome
 information provided in the HSR and we therefore must be able to fetch
 the offending instruction from guest memory and decode it manually.

 We only support instruction decoding for valid reasonable MMIO operations
 where trapping them do not provide sufficient information in the HSR (no
 16-bit Thumb instructions provide register writeback that we care about).

 The following instruciton types are NOT supported for MMIO operations
 despite the HSR not containing decode info:
  - any Load/Store multiple
  - any load/store exclusive
  - any load/store dual
  - anything with the PC as the dest register

 [...]

 +
 +/**
 + * Load-Store instruction emulation
 + 
 */
 +
 +/*
 + * Must be ordered with LOADS first and WRITES afterwards
 + * for easy distinction when doing MMIO.
 + */
 +#define NUM_LD_INSTR  9
 +enum INSTR_LS_INDEXES {
 +   INSTR_LS_LDRBT, INSTR_LS_LDRT, INSTR_LS_LDR, INSTR_LS_LDRB,
 +   INSTR_LS_LDRD, INSTR_LS_LDREX, INSTR_LS_LDRH, INSTR_LS_LDRSB,
 +   INSTR_LS_LDRSH,
 +   INSTR_LS_STRBT, INSTR_LS_STRT, INSTR_LS_STR, INSTR_LS_STRB,
 +   INSTR_LS_STRD, INSTR_LS_STREX, INSTR_LS_STRH,
 +   NUM_LS_INSTR
 +};
 +
 +static u32 ls_instr[NUM_LS_INSTR][2] = {
 +   {0x0470, 0x0d70}, /* LDRBT */
 +   {0x0430, 0x0d70}, /* LDRT  */
 +   {0x0410, 0x0c50}, /* LDR   */
 +   {0x0450, 0x0c50}, /* LDRB  */
 +   {0x00d0, 0x0e1000f0}, /* LDRD  */
 +   {0x01900090, 0x0ff000f0}, /* LDREX */
 +   {0x001000b0, 0x0e1000f0}, /* LDRH  */
 +   {0x001000d0, 0x0e1000f0}, /* LDRSB */
 +   {0x001000f0, 0x0e1000f0}, /* LDRSH */
 +   {0x0460, 0x0d70}, /* STRBT */
 +   {0x0420, 0x0d70}, /* STRT  */
 +   {0x0400, 0x0c50}, /* STR   */
 +   {0x0440, 0x0c50}, /* STRB  */
 +   {0x00f0, 0x0e1000f0}, /* STRD  */
 +   {0x01800090, 0x0ff000f0}, /* STREX */
 +   {0x00b0, 0x0e1000f0}  /* STRH  */
 +};
 +
 +static inline int get_arm_ls_instr_index(u32 instr)
 +{
 +   return kvm_instr_index(instr, ls_instr, NUM_LS_INSTR);
 +}
 +
 +/*
 + * Load-Store instruction decoding
 + */
 +#define INSTR_LS_TYPE_BIT  26
 +#define INSTR_LS_RD_MASK   0xf000
 +#define INSTR_LS_RD_SHIFT  12
 +#define INSTR_LS_RN_MASK   0x000f
 +#define INSTR_LS_RN_SHIFT  16
 +#define INSTR_LS_RM_MASK   0x000f
 +#define INSTR_LS_OFFSET12_MASK 0x0fff

 I'm afraid you're not going to thank me much for this, but it's high time we
 unified the various instruction decoding functions we have under arch/arm/
 and this seems like a good opportunity for that. For example, look at the
 following snippets (there is much more in the files I list) in addition to
 what you have:


I think it would be great if we had a set of unified decoding functions!

However, I think it's a shame if we can't merge KVM because we want to
clean up this code. There would be nothing in the way of breaking API
or anything like that preventing us from cleaning this up after the
code has been merged.

Please consider reviewing the code for correctness and consider if the
code could be merged as is.

On the other hand, if you or Dave or anyone else wants to create a set
of patches that cleans this up in a timely manner, I will be happy to
merge them for my code as well ;)


 asm/ptrace.h
 -
 #define PSR_T_BIT   0x0020
 #define PSR_F_BIT   0x0040
 #define PSR_I_BIT   0x0080
 #define PSR_A_BIT   0x0100
 #define PSR_E_BIT   0x0200
 #define PSR_J_BIT   0x0100
 #define PSR_Q_BIT   0x0800
 #define PSR_V_BIT   0x1000
 #define PSR_C_BIT   0x2000
 #define PSR_Z_BIT   0x4000
 #define PSR_N_BIT   0x8000

 mm/alignment.c
 --
 #define LDST_I_BIT(i)   (i  (1  26)) /* Immediate constant   */
 #define LDST_P_BIT(i)   (i  (1  24)) /* Preindex */
 #define LDST_U_BIT(i)   (i  (1  23)) /* Add offset   */
 #define LDST_W_BIT(i)   (i  (1  21)) /* Writeback*/
 #define LDST_L_BIT(i)   (i  (1  20)) /* Load */

 kernel/kprobes*.c
 -
 static void __kprobes
 emulate_ldr(struct kprobe *p, struct pt_regs *regs)
 {
 kprobe_opcode_t insn = p-opcode;
   

Re: [PATCH 1/1] kvmclock: fix guest stop notification

[Marcelo Tosatti]

On Thu, Sep 20, 2012 at 09:46:41AM -0300, Marcelo Tosatti wrote:
 On Thu, Sep 20, 2012 at 01:55:20PM +0530, Amit Shah wrote:
  Commit f349c12c0434e29c79ecde89029320c4002f7253 added the guest stop
  notification, but it did it in a way that the stop notification would
  never reach the kernel.  The kvm_vm_state_changed() function gets a
  value of 0 for the 'running' parameter when the VM is stopped, making
  all the code added previously dead code.
  
  This patch reworks the code so that it's called when 'running' is 0,
  which indicates the VM was stopped.
  
  CC: Eric B Munson emun...@mgebm.net
  CC: Raghavendra K T raghavendra...@linux.vnet.ibm.com
  CC: Andreas Färber afaer...@suse.de
  CC: Marcelo Tosatti mtosa...@redhat.com
  CC: Paolo Bonzini pbonz...@redhat.com
  CC: Laszlo Ersek ler...@redhat.com
  Signed-off-by: Amit Shah amit.s...@redhat.com
  ---
   hw/kvm/clock.c |   21 +++--
   1 files changed, 11 insertions(+), 10 deletions(-)
  
  diff --git a/hw/kvm/clock.c b/hw/kvm/clock.c
  index 824b978..f3427eb 100644
  --- a/hw/kvm/clock.c
  +++ b/hw/kvm/clock.c
  @@ -71,18 +71,19 @@ static void kvmclock_vm_state_change(void *opaque, int 
  running,
   
   if (running) {
   s-clock_valid = false;
  +return;
  +}
   
  -if (!cap_clock_ctrl) {
  -return;
  -}
  -for (penv = first_cpu; penv != NULL; penv = penv-next_cpu) {
  -ret = kvm_vcpu_ioctl(penv, KVM_KVMCLOCK_CTRL, 0);
  -if (ret) {
  -if (ret != -EINVAL) {
  -fprintf(stderr, %s: %s\n, __func__, strerror(-ret));
  -}
  -return;
  +if (!cap_clock_ctrl) {
  +return;
  +}
  +for (penv = first_cpu; penv != NULL; penv = penv-next_cpu) {
  +ret = kvm_vcpu_ioctl(penv, KVM_KVMCLOCK_CTRL, 0);
  +if (ret) {
  +if (ret != -EINVAL) {
  +fprintf(stderr, %s: %s\n, __func__, strerror(-ret));
   }
  +return;
   }
   }
   }
  -- 
  1.7.7.6
 
 ACK
 
 Avi, please merge through uq/master.

NACK, guest should be notified when the VM is starting, not
when stopping.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: qemu-kvm: remove boot=on|off drive parameter compatibility

[Amos Kong]

- Original Message -
 
 Option is deprecated and warning has been in place for one year.
 
 Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
 
 diff --git a/blockdev.c b/blockdev.c
 index 4a5266e..7c83baa 100644
 --- a/blockdev.c
 +++ b/blockdev.c
 @@ -432,12 +432,6 @@ DriveInfo *drive_init(QemuOpts *opts, int
 default_to_scsi)
  return NULL;
  }
  
 -if (qemu_opt_get(opts, boot) != NULL) {
 -fprintf(stderr, qemu-kvm: boot=on|off is deprecated and
 will be 
 -ignored. Future versions will reject this
 parameter. Please 
 -update your scripts.\n);
 -}
 -
  on_write_error = BLOCK_ERR_STOP_ENOSPC;
  if ((buf = qemu_opt_get(opts, werror)) != NULL) {
  if (type != IF_IDE  type != IF_SCSI  type != IF_VIRTIO
   type != IF_NONE) {
 diff --git a/qemu-config.c b/qemu-config.c
 index 3eaee48..eba977e 100644
 --- a/qemu-config.c
 +++ b/qemu-config.c
 @@ -114,10 +114,6 @@ static QemuOptsList qemu_drive_opts = {
  .name = copy-on-read,
  .type = QEMU_OPT_BOOL,
  .help = copy read data from backing file into image
  file,
 -},{
 -.name = boot,
 -.type = QEMU_OPT_BOOL,
 -.help = (deprecated, ignored),
  },
  { /* end of list */ }
  },


Reviewed-by: Amos Kong ak...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] kvmclock: fix guest stop notification

[Amos Kong]

- Original Message -
 On Thu, Sep 20, 2012 at 09:46:41AM -0300, Marcelo Tosatti wrote:
  On Thu, Sep 20, 2012 at 01:55:20PM +0530, Amit Shah wrote:
   Commit f349c12c0434e29c79ecde89029320c4002f7253 added the guest
   stop

In commitlog of f349c12c0434e29c79ecde89029320c4002f7253: 

## This patch uses the qemu Notifier system to tell the guest it _is about to 
be_ stopped


   notification, but it did it in a way that the stop notification
   would
   never reach the kernel.  The kvm_vm_state_changed() function gets
   a
   value of 0 for the 'running' parameter when the VM is stopped,
   making
   all the code added previously dead code.
   
   This patch reworks the code so that it's called when 'running' is
   0,
   which indicates the VM was stopped.

Amit, did you touch any real issue? guest gets call trace with current code?
which kind of context?

Someone told me he got call trace when shutdown guest by 'init 0', I didn't
verify this issue.

   CC: Eric B Munson emun...@mgebm.net
   CC: Raghavendra K T raghavendra...@linux.vnet.ibm.com
   CC: Andreas Färber afaer...@suse.de
   CC: Marcelo Tosatti mtosa...@redhat.com
   CC: Paolo Bonzini pbonz...@redhat.com
   CC: Laszlo Ersek ler...@redhat.com
   Signed-off-by: Amit Shah amit.s...@redhat.com
   ---
hw/kvm/clock.c |   21 +++--
1 files changed, 11 insertions(+), 10 deletions(-)
   
   diff --git a/hw/kvm/clock.c b/hw/kvm/clock.c
   index 824b978..f3427eb 100644
   --- a/hw/kvm/clock.c
   +++ b/hw/kvm/clock.c
   @@ -71,18 +71,19 @@ static void kvmclock_vm_state_change(void
   *opaque, int running,


I found this function is only called when resume vm
(here running is 1, it means vm is already resumed?
we don't call that ioctl _before_ resume).

kvmclock_vm_state_change() is not called when I stop vm
through qemu monitor command.



if (running) {
s-clock_valid = false;
   +return;
   +}

   -if (!cap_clock_ctrl) {
   -return;
   -}
   -for (penv = first_cpu; penv != NULL; penv =
   penv-next_cpu) {
   -ret = kvm_vcpu_ioctl(penv, KVM_KVMCLOCK_CTRL, 0);
   -if (ret) {
   -if (ret != -EINVAL) {
   -fprintf(stderr, %s: %s\n, __func__,
   strerror(-ret));
   -}
   -return;
   +if (!cap_clock_ctrl) {
   +return;
   +}
   +for (penv = first_cpu; penv != NULL; penv = penv-next_cpu)
   {
   +ret = kvm_vcpu_ioctl(penv, KVM_KVMCLOCK_CTRL, 0);
   +if (ret) {
   +if (ret != -EINVAL) {
   +fprintf(stderr, %s: %s\n, __func__,
   strerror(-ret));
}
   +return;
}
}
}
   --
   1.7.7.6
  
  ACK
  
  Avi, please merge through uq/master.
 
 NACK, guest should be notified when the VM is starting, not
 when stopping.

# from api.txt
ioctl (KVM_CAP_KVMCLOCK_CTRL) can be called any time _after_ pausing
the vcpu, but _before_ it is resumed.


Thanks, Amos
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 03/15] ARM: Section based HYP idmap

[Christoffer Dall]

[snip]

 +
 +static int __init hyp_init_static_idmap(void)
 +{
 + hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
 + if (!hyp_pgd)
 + return -ENOMEM;
 +
 + hyp_idmap_setup();
 +
 + return 0;
 +}
 +early_initcall(hyp_init_static_idmap);
 +#endif

 I'd rather the alloc/free functions for the hyp pgd were somewhere else,
 like they are for standard pgds. Then we can just call them here without
 having to encode knowledge of PGD size etc in the mapping code.

this used to be the case, but Marc changed it iirc., so just cc'ing
him. The following is an attempt at what you're looking for if I
understand you correctly:

diff --git a/arch/arm/include/asm/idmap.h b/arch/arm/include/asm/idmap.h
index a1ab8d6..36708ba 100644
--- a/arch/arm/include/asm/idmap.h
+++ b/arch/arm/include/asm/idmap.h
@@ -12,10 +12,8 @@ extern pgd_t *idmap_pgd;
 void setup_mm_for_reboot(void);

 #ifdef CONFIG_ARM_VIRT_EXT
-extern pgd_t *hyp_pgd;
-
-void hyp_idmap_teardown(void);
-void hyp_idmap_setup(void);
+void hyp_idmap_teardown(pgd_t *hyp_pgd);
+void hyp_idmap_setup(pgd_t *hyp_pgd);
 #endif

 #endif /* __ASM_IDMAP_H */
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index c3f90b0..ecfaaf0 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -43,4 +43,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu,
struct kvm_run *run);

 void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu);

+unsigned long kvm_mmu_get_httbr(void);
+int kvm_mmu_init(void);
+void kvm_mmu_exit(void);
 #endif /* __ARM_KVM_MMU_H__ */
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 7e11280..d64ce2a 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -35,7 +35,6 @@
 #include asm/ptrace.h
 #include asm/mman.h
 #include asm/cputype.h
-#include asm/idmap.h
 #include asm/tlbflush.h
 #include asm/cacheflush.h
 #include asm/virt.h
@@ -887,7 +886,7 @@ static void cpu_init_hyp_mode(void *vector)
/* Switch from the HYP stub to our own HYP init vector */
__hyp_set_vectors((unsigned long)vector);

-   pgd_ptr = virt_to_phys(hyp_pgd);
+   pgd_ptr = kvm_mmu_get_httbr();
stack_page = __get_cpu_var(kvm_arm_hyp_stack_page);
hyp_stack_ptr = stack_page + PAGE_SIZE;
vector_ptr = (unsigned long)__kvm_hyp_vector;
@@ -918,6 +917,13 @@ static int init_hyp_mode(void)
int err = 0;

/*
+* Allocate Hyp PGD and setup Hyp identity mapping
+*/
+   err = kvm_mmu_init();
+   if (err)
+   return err;
+
+   /*
 * It is probably enough to obtain the default on one
 * CPU. It's unlikely to be different on the others.
 */
@@ -954,7 +960,7 @@ static int init_hyp_mode(void)
/*
 * Unmap the identity mapping
 */
-   hyp_idmap_teardown();
+   kvm_mmu_exit();

/*
 * Map the Hyp-code called directly from the host
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 9499d4d..a35a8a9 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -34,6 +34,7 @@
 #include trace.h

 static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
+static pgd_t *hyp_pgd;

 static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
  int min, int max)
@@ -994,3 +995,23 @@ void kvm_mmu_free_memory_caches(struct kvm_vcpu *vcpu)
 {
mmu_free_memory_cache(vcpu-arch.mmu_page_cache);
 }
+
+unsigned long kvm_mmu_get_httbr(void)
+{
+   return virt_to_phys(hyp_pgd);
+}
+
+int kvm_mmu_init(void)
+{
+   hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
+   if (!hyp_pgd)
+   return -ENOMEM;
+
+   hyp_idmap_setup(hyp_pgd);
+   return 0;
+}
+
+void kvm_mmu_exit(void)
+{
+   hyp_idmap_teardown(hyp_pgd);
+}
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index f0ab339..ea7430e 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -102,9 +102,6 @@ static int __init init_static_idmap(void)
 early_initcall(init_static_idmap);

 #if defined(CONFIG_ARM_VIRT_EXT)  defined(CONFIG_ARM_LPAE)
-pgd_t *hyp_pgd;
-EXPORT_SYMBOL_GPL(hyp_pgd);
-
 static void hyp_idmap_del_pmd(pgd_t *pgd, unsigned long addr)
 {
pud_t *pud;
@@ -123,7 +120,7 @@ extern char  __hyp_idmap_text_start[],
__hyp_idmap_text_end[];
  * This version actually frees the underlying pmds for all pgds in range and
  * clear the pgds themselves afterwards.
  */
-void hyp_idmap_teardown(void)
+void hyp_idmap_teardown(pgd_t *hyp_pgd)
 {
unsigned long addr, end;
unsigned long next;
@@ -141,27 +138,12 @@ void hyp_idmap_teardown(void)
 }
 EXPORT_SYMBOL_GPL(hyp_idmap_teardown);

-void hyp_idmap_setup(void)
+void hyp_idmap_setup(pgd_t *hyp_pgd)
 {
identity_mapping_add(hyp_pgd, __hyp_idmap_text_start,
 __hyp_idmap_text_end, PMD_SECT_AP1);
 }
 EXPORT_SYMBOL_GPL(hyp_idmap_setup);
-
-static int __init hyp_init_static_idmap(void)
-{
-   if 

Re: resize raw images

[Kazuo Moriwaka]

From: Lentes, Bernd bernd.len...@helmholtz-muenchen.de
Subject: resize raw images
Date: Fri, 28 Sep 2012 18:14:45 +0200
 I also have to create some new vm's. What is when disk space is running out ? 
 My idea is to create the new vm's in raw images. Inside the vm, filesystems 
 will reside in logical volumes. When disk space is running out, i resize the 
 raw image using:
 
 - qemu-img create -f raw additional.raw size
 - cat additional.raw  vm.raw
 - inside the vm, resize the filesystems easily with lvm tools und resize2fs.
 
 What do you think about this idea ? Are there easier solutions ?

This question will be good at virt-tools-list.
http://www.redhat.com/mailman/listinfo/virt-tools-list
http://virt-tools.org/
 
And virt-resize will be what you want.
http://libguestfs.org/virt-resize.1.html

Regards,
-- 
Kazuo Moriwaka

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] KVM: PPC: e500: fix allocation size error on g2h_tlb1_map

[Avi Kivity]

On 09/27/2012 09:59 PM, Alexander Graf wrote:
 
 Do you have the auto-autotest setup ready?  I guess we can do it
 manually until it is.
 
 I do have a local autotest setup. Or what exactly are you referring to?

Getting autotest to run automatically and produce readable reports, and
auto-bisection.

-- 
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html