On Thu, 7 Jan 2010, Michael S. Tsirkin wrote:
> OK. What I think we need is a way to remove ourselves from the eventfd
> wait queue and clear the counter atomically.
>
> We currently do
> remove_wait_queue(irqfd->wqh, &irqfd->wait);
> where wqh saves the eventfd wait queue head.
You do a
On Wed, Jan 06, 2010 at 03:59:11PM -0800, Davide Libenzi wrote:
> On Thu, 7 Jan 2010, Michael S. Tsirkin wrote:
>
> > On Wed, Jan 06, 2010 at 02:46:06PM -0800, Davide Libenzi wrote:
> > > On Thu, 7 Jan 2010, Michael S. Tsirkin wrote:
> > >
> > > > > On top of creating an interface which requires
On Wed, Jan 06, 2010 at 04:42:30PM -0600, Anthony Liguori wrote:
> On 01/06/2010 02:37 PM, Gleb Natapov wrote:
> >We have exactly that hook in apic already and that's how RTC determines
> >that interrupt was coalesced.
>
> AFAICT, apic_irq_delivered is only reset explicitly by the RTC when
> the l
On Thursday 07 January 2010 02:36:26 Beth Kon wrote:
> Dor Laor wrote:
> > On 01/06/2010 12:09 PM, Gleb Natapov wrote:
> >> On Wed, Jan 06, 2010 at 05:48:52PM +0800, Sheng Yang wrote:
> >>> Hi Beth
> >>>
> >>> I still found the emulated HPET would result in some boot failure. For
> >>> example, on
On Wed, Jan 06, 2010 at 03:59:11PM -0800, Davide Libenzi wrote:
> On Thu, 7 Jan 2010, Michael S. Tsirkin wrote:
>
> > On Wed, Jan 06, 2010 at 02:46:06PM -0800, Davide Libenzi wrote:
> > > On Thu, 7 Jan 2010, Michael S. Tsirkin wrote:
> > >
> > > > > On top of creating an interface which requires
On Thu, 7 Jan 2010, Michael S. Tsirkin wrote:
> On Wed, Jan 06, 2010 at 02:46:06PM -0800, Davide Libenzi wrote:
> > On Thu, 7 Jan 2010, Michael S. Tsirkin wrote:
> >
> > > > On top of creating an interface which requires a lock, which noone can
> > > > get
> > > > from the interface itself, sin
On Wed, Jan 06, 2010 at 02:46:06PM -0800, Davide Libenzi wrote:
> On Thu, 7 Jan 2010, Michael S. Tsirkin wrote:
>
> > > On top of creating an interface which requires a lock, which noone can
> > > get
> > > from the interface itself, since it's not exposed.
> >
> > I think here's how KVM gets i
On Thu, 7 Jan 2010, Michael S. Tsirkin wrote:
> > On top of creating an interface which requires a lock, which noone can get
> > from the interface itself, since it's not exposed.
>
> I think here's how KVM gets it: the way it does is by calling poll with
> our own poll table, then in poll_queue
On 01/06/2010 02:37 PM, Gleb Natapov wrote:
We have exactly that hook in apic already and that's how RTC determines
that interrupt was coalesced.
AFAICT, apic_irq_delivered is only reset explicitly by the RTC when the
line is lowered. It's not currently lowered based on EOI.
How can thi
On Wed, Jan 06, 2010 at 01:17:02PM -0800, Davide Libenzi wrote:
> On Wed, 6 Jan 2010, Michael S. Tsirkin wrote:
>
> > I tried to explain, no? That patch was taking wait queue spinlock and
> > was assuming that eventfd_read_ctx is called from a task that can block.
> > KVM attaches its own poller
Anthony Liguori wrote:
What about just adding back this bit:
@@ -165,6 +165,8 @@ static void CONCAT(send_hextile_tile_,
NAME)(VncState *vs,
irow += ds_get_linesize(vs->ds) / sizeof(pixel_t);
}
+/* A SubrectsColoured subtile invalidates the foreground color */
+*has_fg =
On Wed, 6 Jan 2010, Michael S. Tsirkin wrote:
> I tried to explain, no? That patch was taking wait queue spinlock and
> was assuming that eventfd_read_ctx is called from a task that can block.
> KVM attaches its own poller so this is not a good fit for us. Hope this
> clarifies.
>
> > and yet a
On Wed, Jan 06, 2010 at 12:43:07PM -0800, Davide Libenzi wrote:
> On Wed, 6 Jan 2010, Michael S. Tsirkin wrote:
>
> > On Tue, Sep 01, 2009 at 07:24:24AM -0700, Davide Libenzi wrote:
> > > On Tue, 1 Sep 2009, Avi Kivity wrote:
> > >
> > > > On 09/01/2009 02:45 AM, Davide Libenzi wrote:
> > > > > O
On Wed, 6 Jan 2010, Michael S. Tsirkin wrote:
> On Tue, Sep 01, 2009 at 07:24:24AM -0700, Davide Libenzi wrote:
> > On Tue, 1 Sep 2009, Avi Kivity wrote:
> >
> > > On 09/01/2009 02:45 AM, Davide Libenzi wrote:
> > > > On Thu, 27 Aug 2009, Davide Libenzi wrote:
> > > >
> > > >
> > > > > On Th
On Wed, Jan 06, 2010 at 01:51:54PM -0600, Anthony Liguori wrote:
> On 01/06/2010 01:44 PM, Gleb Natapov wrote:
> >On Wed, Jan 06, 2010 at 01:23:28PM -0600, Anthony Liguori wrote:
> >>On 01/06/2010 01:20 PM, Beth Kon wrote:
> >>>Beth Kon wrote:
> I will try to look into this. Since HPET is edge-
On 01/06/2010 01:44 PM, Gleb Natapov wrote:
On Wed, Jan 06, 2010 at 01:23:28PM -0600, Anthony Liguori wrote:
On 01/06/2010 01:20 PM, Beth Kon wrote:
Beth Kon wrote:
I will try to look into this. Since HPET is edge-triggered,
looks like this problem is of a different nature th
Signed-off-by: Bruce Rogers
---
qemu-options.hx | 58 --
1 files changed, 30 insertions(+), 28 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 812d067..fdd5884 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -42,7 +42,
On Wed, Jan 06, 2010 at 01:23:28PM -0600, Anthony Liguori wrote:
> On 01/06/2010 01:20 PM, Beth Kon wrote:
> >Beth Kon wrote:
> >>I will try to look into this. Since HPET is edge-triggered,
> >>looks like this problem is of a different nature than PIT. Is
> >>this a solid failure or intermittent?
On Tue, Sep 01, 2009 at 07:24:24AM -0700, Davide Libenzi wrote:
> On Tue, 1 Sep 2009, Avi Kivity wrote:
>
> > On 09/01/2009 02:45 AM, Davide Libenzi wrote:
> > > On Thu, 27 Aug 2009, Davide Libenzi wrote:
> > >
> > >
> > > > On Thu, 27 Aug 2009, Michael S. Tsirkin wrote:
> > > >
> > > >
On 01/06/2010 01:20 PM, Beth Kon wrote:
Beth Kon wrote:
I will try to look into this. Since HPET is edge-triggered, looks
like this problem is of a different nature than PIT. Is this a solid
failure or intermittent?
Anthony just explained that on x86, even edge-triggered interrupts are
queued
Beth Kon wrote:
Dor Laor wrote:
On 01/06/2010 12:09 PM, Gleb Natapov wrote:
On Wed, Jan 06, 2010 at 05:48:52PM +0800, Sheng Yang wrote:
Hi Beth
I still found the emulated HPET would result in some boot failure. For
example, on my 2.6.30, with HPET enabled, the kernel would fail
check_timer()
On 01/06/2010 07:51 AM, Marcelo Tosatti wrote:
On Tue, Jan 05, 2010 at 04:11:26PM +, Mark Cave-Ayland wrote:
Hi all,
Having just upgraded from kvm-85 to qemu-kvm-0.12.1.1 on one of our
servers, I've noticed that I am seeing block artefacts when connecting
using VNC to the graphical VGA
Dor Laor wrote:
On 01/06/2010 12:09 PM, Gleb Natapov wrote:
On Wed, Jan 06, 2010 at 05:48:52PM +0800, Sheng Yang wrote:
Hi Beth
I still found the emulated HPET would result in some boot failure. For
example, on my 2.6.30, with HPET enabled, the kernel would fail
check_timer(),
especially in
On Wed, Jan 06, 2010 at 11:58:14AM -0600, Anthony Liguori wrote:
> On 01/06/2010 07:51 AM, Marcelo Tosatti wrote:
>> On Tue, Jan 05, 2010 at 04:11:26PM +, Mark Cave-Ayland wrote:
>>
>>> Hi all,
>>>
>>> Having just upgraded from kvm-85 to qemu-kvm-0.12.1.1 on one of our
>>> servers, I've not
On 01/06/2010 07:51 AM, Marcelo Tosatti wrote:
On Tue, Jan 05, 2010 at 04:11:26PM +, Mark Cave-Ayland wrote:
Hi all,
Having just upgraded from kvm-85 to qemu-kvm-0.12.1.1 on one of our
servers, I've noticed that I am seeing block artefacts when connecting
using VNC to the graphical VGA
Mark Cave-Ayland wrote:
A quick search took me to this page here:
http://blogs.msdn.com/virtual_pc_guy/archive/2005/10/24/484461.aspx
which explains the issue in more detail. I first tried disabling the
intelppm driver and rebooting, but that didn't make a difference;
however disabling the Pr
Avi Kivity wrote:
It probably did make some kind of difference. Please try a clean install.
After several hours of testing, I've finally found out what the problem is.
I tried a clean WinXP guest install and that worked, so it was obviously
a driver issue. After disabling various drivers in
Marcelo Tosatti wrote:
Mark,
Can you confirm that reverting commit
02c2b87fff97e77a1f6033fb09f53afa267c0c1e fixes the problem? (patch
attached).
Anthony: its reproducible with upstream/tcg.
Hi Marcelo,
Yes, this solves the problem for me - thanks a lot!
FWIW there is still another race con
On Wed, Jan 6, 2010 at 10:59 PM, Marcelo Tosatti wrote:
> On Wed, Jan 06, 2010 at 10:07:25PM +0900, Ryota Ozaki wrote:
>> Hi all,
>>
>> I would like to know the state of guest memory
>> hotplug support.
>>
>> Is the feature already supported?
>
> No.
>
>> Otherwise, is anyone working on that?
>
>
On Wed, Jan 06, 2010 at 10:07:25PM +0900, Ryota Ozaki wrote:
> Hi all,
>
> I would like to know the state of guest memory
> hotplug support.
>
> Is the feature already supported?
No.
> Otherwise, is anyone working on that?
Not that i know of.
> I know virtio balloon can changes amount of
> gu
On Tue, Jan 05, 2010 at 04:11:26PM +, Mark Cave-Ayland wrote:
> Hi all,
>
> Having just upgraded from kvm-85 to qemu-kvm-0.12.1.1 on one of our
> servers, I've noticed that I am seeing block artefacts when connecting
> using VNC to the graphical VGA console of a WinXP guest.
>
> Looking at
On 1/6/2010 3:14 PM, Mark Cave-Ayland wrote:
Gleb Natapov wrote:
Can you start is in safe mode and see which driver fails?
Hmmm. Booting in Safe Mode seems to work fine, although the next
attempt to boot into Normal Mode returns a BSOD with
"INTERNAL_POWER_ERROR" which is new to me. Subsequ
Gleb Natapov wrote:
Can you start is in safe mode and see which driver fails?
Hmmm. Booting in Safe Mode seems to work fine, although the next attempt
to boot into Normal Mode returns a BSOD with "INTERNAL_POWER_ERROR"
which is new to me. Subsequent reboots then return to the
"DRIVER_UNLOAD
Hi all,
I would like to know the state of guest memory
hotplug support.
Is the feature already supported?
Otherwise, is anyone working on that?
I know virtio balloon can changes amount of
guest memory online, however, it can change
only under initially assigned amount of memory.
I want to increa
On 01/06/2010 02:50 PM, Mark Cave-Ayland wrote:
Avi Kivity wrote:
Did you install using 0.12.1.1 and then run using 0.12.1.2? If so,
it seems Windows XP is not able to move from AMD to Intel.
No, although the original VM was built in VirtualBox if that makes a
difference? I had to manually
On Wed, Jan 06, 2010 at 12:50:29PM +, Mark Cave-Ayland wrote:
> Avi Kivity wrote:
>
> >Did you install using 0.12.1.1 and then run using 0.12.1.2? If
> >so, it seems Windows XP is not able to move from AMD to Intel.
>
> No, although the original VM was built in VirtualBox if that makes a
> d
On Wed, Jan 06, 2010 at 12:50:29PM +, Mark Cave-Ayland wrote:
> Avi Kivity wrote:
>
> >Did you install using 0.12.1.1 and then run using 0.12.1.2? If
> >so, it seems Windows XP is not able to move from AMD to Intel.
>
> No, although the original VM was built in VirtualBox if that makes a
> d
Avi Kivity wrote:
Did you install using 0.12.1.1 and then run using 0.12.1.2? If so, it
seems Windows XP is not able to move from AMD to Intel.
No, although the original VM was built in VirtualBox if that makes a
difference? I had to manually implement the "merge ide" fix here
(http://suppo
Marcelo Tosatti wrote:
> Mark,
>
> Thanks for tracking it down. Is there any difference with "-cpu host"
> option?
Yeah; if I launch 0.12.1.1 which normally works with an additional "-cpu
host" option then kvm crashes in exactly the same way.
HTH,
Mark.
--
Mark Cave-Ayland - Senior Technic
On 01/06/2010 01:25 PM, Mark Cave-Ayland wrote:
Good news - I downloaded the userspace git repository and managed to
identify the offending commit between 0.12.1.1 and 0.12.1.2 using git
bisect:
4dad7ff32aa6dcf18cef0c606d8fb43ff0b939a1 is first bad commit
commit 4dad7ff32aa6dcf18cef0c606d8fb4
On Wed, Jan 06, 2010 at 02:33:36PM +0200, Gleb Natapov wrote:
> On Wed, Jan 06, 2010 at 10:29:18AM -0200, Marcelo Tosatti wrote:
> > On Wed, Jan 06, 2010 at 11:25:14AM +, Mark Cave-Ayland wrote:
> > > Avi Kivity wrote:
> > >
> > >>> I think I'm experiencing a regression with the new qemu-kvm-0.
On Wed, Jan 06, 2010 at 10:29:18AM -0200, Marcelo Tosatti wrote:
> On Wed, Jan 06, 2010 at 11:25:14AM +, Mark Cave-Ayland wrote:
> > Avi Kivity wrote:
> >
> >>> I think I'm experiencing a regression with the new qemu-kvm-0.12.1.2
> >>> release compared to qemu-kvm-0.12.1.1 with a WinXP guest
On Wed, Jan 06, 2010 at 11:25:14AM +, Mark Cave-Ayland wrote:
> Avi Kivity wrote:
>
>>> I think I'm experiencing a regression with the new qemu-kvm-0.12.1.2
>>> release compared to qemu-kvm-0.12.1.1 with a WinXP guest on Linux.
>>>
>>> I can boot my WinXP guest without a problem under qemu-kv
Avi Kivity wrote:
I think I'm experiencing a regression with the new qemu-kvm-0.12.1.2
release compared to qemu-kvm-0.12.1.1 with a WinXP guest on Linux.
I can boot my WinXP guest without a problem under qemu-kvm-0.12.1.1,
however under qemu-kvm-0.12.1.2 a couple of seconds after reaching the
On 01/06/2010 12:47 PM, Joerg Roedel wrote:
On Wed, Jan 06, 2010 at 05:18:13AM +0200, Avi Kivity wrote:
Joerg, what was the reason the initial npt implementation did not do
lazy fpu switching?
The lazy fpu switching code needed cr3 accesses to be intercepted. With
NPT this was the onl
On Wed, Jan 06, 2010 at 05:18:13AM +0200, Avi Kivity wrote:
> Joerg, what was the reason the initial npt implementation did not do
> lazy fpu switching?
The lazy fpu switching code needed cr3 accesses to be intercepted. With
NPT this was the only reason left to intercept cr3 so I decided to
switch
On 01/06/2010 12:09 PM, Gleb Natapov wrote:
On Wed, Jan 06, 2010 at 05:48:52PM +0800, Sheng Yang wrote:
Hi Beth
I still found the emulated HPET would result in some boot failure. For
example, on my 2.6.30, with HPET enabled, the kernel would fail check_timer(),
especially in timer_irq_works().
On Wed, Jan 06, 2010 at 07:17:30PM +0900, Jun Koi wrote:
> On Wed, Jan 6, 2010 at 1:04 AM, Avi Kivity wrote:
> > On 01/05/2010 05:05 PM, Jun Koi wrote:
> >>
> >> Is it true that to make this work, we will need a (PV) kernel driver
> >> for each guest OS (Windows, Linux, ...)?
> >>
> >>
> >
> > It'
On Wed, Jan 6, 2010 at 1:04 AM, Avi Kivity wrote:
> On 01/05/2010 05:05 PM, Jun Koi wrote:
>>
>> Is it true that to make this work, we will need a (PV) kernel driver
>> for each guest OS (Windows, Linux, ...)?
>>
>>
>
> It's partially usable even without guest modifications; while servicing a
> ho
On Wed, Jan 06, 2010 at 05:48:52PM +0800, Sheng Yang wrote:
> Hi Beth
>
> I still found the emulated HPET would result in some boot failure. For
> example, on my 2.6.30, with HPET enabled, the kernel would fail
> check_timer(),
> especially in timer_irq_works().
>
> The testing of timer_irq_wo
On Wed, Jan 06, 2010 at 05:25:27PM +0800, Sheng Yang wrote:
> > > - for (level = PT_DIRECTORY_LEVEL; level <= host_level; ++level)
> > > + max_level = kvm_x86_ops->get_lpage_level() < host_level ?
> > > + kvm_x86_ops->get_lpage_level() : host_level;
> > > +
> >
> > BUG_ON(kvm_x86_ops->get_
Hi Beth
I still found the emulated HPET would result in some boot failure. For
example, on my 2.6.30, with HPET enabled, the kernel would fail check_timer(),
especially in timer_irq_works().
The testing of timer_irq_works() is let 10 ticks pass(using mdelay()), and
want to confirm the clock so
Marcelo Tosatti schrieb:
> Hum, can you try converting that vmdk image to qcow2 or raw? (with
> qemu-img convert).
>
> AFAICS the QEMU vmdk implementation is synchronous, so the guest
> waits on IO operations to complete on the host side.
I'll do so, but I can only make the conversion early mor
On Wed, Jan 06, 2010 at 09:15:02AM +0100, Martin Schmitt wrote:
> Marcelo Tosatti schrieb:
>
> > Can you please share a few more "soft lockup" messages? (with
> > backtrace included).
>
> Full dmesg from guest: http://pastebin.com/f51a966df
>
> > Also qemu command line.
>
> >From ps:
>
> /usr/
On Wednesday 06 January 2010 17:19:15 Marcelo Tosatti wrote:
> On Tue, Jan 05, 2010 at 07:02:29PM +0800, Sheng Yang wrote:
> > Signed-off-by: Sheng Yang
> > ---
> > arch/x86/include/asm/vmx.h |1 +
> > arch/x86/kvm/mmu.c |8 +---
> > arch/x86/kvm/vmx.c | 11 +
Signed-off-by: Pierre Riteau
---
configure |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 81c44e8..4254485 100755
--- a/configure
+++ b/configure
@@ -756,10 +756,10 @@ echo " --disable-bluez disable bluez stack
connectivity"
On Mon, Jan 04, 2010 at 10:19:22PM +0100, Alexander Graf wrote:
> When we're loading bolted entries into the SLB again, we're checking if an
> entry is in use and only slbmte it when it is.
>
> Unfortunately, the check always goes to the skip label of the first entry,
> resulting in an endless loo
On Mon, Jan 04, 2010 at 10:19:25PM +0100, Alexander Graf wrote:
> The PowerPC C ABI defines that registers r14-r31 need to be preserved across
> function calls. Since our exit handler is written in C, we can make use of
> that
> and don't need to reload r14-r31 on every entry/exit cycle.
>
> This
On Tue, Jan 05, 2010 at 07:02:29PM +0800, Sheng Yang wrote:
>
> Signed-off-by: Sheng Yang
> ---
> arch/x86/include/asm/vmx.h |1 +
> arch/x86/kvm/mmu.c |8 +---
> arch/x86/kvm/vmx.c | 11 ++-
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --gi
Marcelo Tosatti schrieb:
> Can you please share a few more "soft lockup" messages? (with
> backtrace included).
Full dmesg from guest: http://pastebin.com/f51a966df
> Also qemu command line.
>From ps:
/usr/local/kvm/bin/qemu-system-x86_64 -hda /drbd/vweb/vweb.vmdk -vnc
127.0.0.1:4 -m 512 -net
The explanation of write_emulated is confused with
that of read_emulated. This patch fix it.
Signed-off-by: Takuya Yoshikawa
---
arch/x86/include/asm/kvm_emulate.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/kvm_emulate.h
b/arch/x86/include/asm
On Wed, Jan 06, 2010 at 04:17:42PM +0800, Huang Ying wrote:
> On Wed, 2010-01-06 at 16:03 +0800, Avi Kivity wrote:
> > On 01/06/2010 09:05 AM, Huang Ying wrote:
> > > @@ -1015,6 +1015,7 @@ void kvm_arch_load_regs(CPUState *env)
> > >>>#endif
> > >>>set_msr_entry(&msrs[n++], MSR_KVM_SYST
On Mon, Jan 04, 2010 at 03:01:29PM +0100, Martin Schmitt wrote:
> Ciao Marcelo,
>
> sorry for getting back so late. Thanks for your patience. :-)
>
> Marcelo Tosatti schrieb:
>
> >> I'm running a manually compiled KVM on CentOS 5.4. The KVM installation
> >> has been carried over from CentOS 5.3
On Mon, Jan 04, 2010 at 09:18:01AM +0100, Thomas Beinicke wrote:
> I get the same message since the update, is it -chardev option related?
>
>
> On Saturday 02 January 2010 11:53:42 Thomas Mueller wrote:
> > hi
> >
> > since 0.12.x i get the following messages starting a vm:
> >
> > Option 'ipv
On Tue, 2010-01-05 at 18:44 +0800, Andi Kleen wrote:
> > --- a/qemu-kvm-x86.c
> > +++ b/qemu-kvm-x86.c
> > @@ -1015,6 +1015,7 @@ void kvm_arch_load_regs(CPUState *env)
> > #endif
> > set_msr_entry(&msrs[n++], MSR_KVM_SYSTEM_TIME, env->system_time_msr);
> > set_msr_entry(&msrs[n++], MSR_
On Wed, 2010-01-06 at 16:03 +0800, Avi Kivity wrote:
> On 01/06/2010 09:05 AM, Huang Ying wrote:
> > @@ -1015,6 +1015,7 @@ void kvm_arch_load_regs(CPUState *env)
> >>>#endif
> >>>set_msr_entry(&msrs[n++], MSR_KVM_SYSTEM_TIME,
> >>> env->system_time_msr);
> >>>set_msr_entry(&ms
On 01/06/2010 09:05 AM, Huang Ying wrote:
@@ -1015,6 +1015,7 @@ void kvm_arch_load_regs(CPUState *env)
#endif
set_msr_entry(&msrs[n++], MSR_KVM_SYSTEM_TIME, env->system_time_msr);
set_msr_entry(&msrs[n++], MSR_KVM_WALL_CLOCK, env->wall_clock_msr);
+set_msr_entry(&msrs[n++]
67 matches
Mail list logo
