Migrating from Xen 3.2 to KVM

[Mike Power]

Hello,

I currently (I think) have XP installed on an LVM
volume /dev/mapper/vol_group1-windows.  I have been trying to power this
VM up on KVM (Ubuntu 8.10 dropped Xen).  Come to think of it I am not
even sure if the on disk format KVM expects is the same the Xen wrote to
disk.

What is the likely hood that I will succeed?

At this time using the attached config file I boot up into the windows
boot strap.  I immediately hit the safe mode menu.  Once I step pass the
safe mode menu then the vm reboots.  Known problem?

Mike Power


windows.xml
Description: XML document

Re: [PATCH] qemu: report issues causing the kvm probe to fail v3

[Christian Ehrhardt]

Anthony Liguori wrote:

ehrha...@linux.vnet.ibm.com wrote:

From: Christian Ehrhardt 

The patch applies to upstream qemu as well as kvm-userspace, but 
since it is
the qemu configure script I think it should go to upstream qemu 
(Anthony)
first and with the next merge to kvm-userspace. On the other hand it 
is the kvm

probe so an ack from Avi in case v3 is ok would be reasonable.

*updates*
v2 - it also reports other errors than just #error preprocessor 
statements

 (requested by Avi)
v3 - In case awk or grep is not installed it now gracfully (silently)
 fails still disabling kvm (requested by Anthony)

This patch is about reporting more details of the issue if 
configuring kvm
fails. Therefore this patch keeps the qemu style configure output 
which is a
list of "$Feature $Status", but extend the "no" result like "KVM 
Support no"

with some more information.

There might be a lot of things going wrong with that probe and I 
don't want

to handle all of them, but if it is one of the known checks e.g. for
KVM_API_VERSION then we could grep/awk that out and report it. The patch
reports in case of a known case in the style
"KVM support no - (Missing KVM capability 
KVM_CAP_DESTROY_MEMORY_REGION_WORKS)"


In case more than one #error is triggered it creates a comma 
separated list in
those brackets and in case it is something else than an #error it 
just reports

plain old "no".

Signed-off-by: Christian Ehrhardt 
---

 configure |   27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/qemu/configure b/qemu/configure
--- a/qemu/configure
+++ b/qemu/configure
  


Please send against upstream QEMU.

Regards,

Anthony Liguori

This applies to qemu upstream already when not specifying -p or -p 2 (as 
I already tested yesterday before submission).
Well I removed the leading qemu dir manually and updated the -51 lines 
offset (attached), should I change more than that (add the leading trunk 
maybe, atm I'm just not sure what changes you want) ?



--

Grüsse / regards, 
Christian Ehrhardt

IBM Linux Technology Center, Open Virtualization

Subject: [PATCH] qemu: report issues causing the kvm probe to fail v3

From: Christian Ehrhardt 

The patch applies to upstream qemu as well as kvm-userspace, but since it is
the qemu configure script I think it should go to upstream qemu (Anthony)
first and with the next merge to kvm-userspace. On the other hand it is the kvm
probe so an ack from Avi in case v3 is ok would be reasonable.

*updates*
v2 - it also reports other errors than just #error preprocessor statements
 (requested by Avi)
v3 - In case awk or grep is not installed it now gracfully (silently)
 fails still disabling kvm (requested by Anthony)

This patch is about reporting more details of the issue if configuring kvm
fails. Therefore this patch keeps the qemu style configure output which is a
list of "$Feature $Status", but extend the "no" result like "KVM Support no"
with some more information.

There might be a lot of things going wrong with that probe and I don't want
to handle all of them, but if it is one of the known checks e.g. for
KVM_API_VERSION then we could grep/awk that out and report it. The patch
reports in case of a known case in the style
"KVM support no - (Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS)"

In case more than one #error is triggered it creates a comma separated list in
those brackets and in case it is something else than an #error it just reports
plain old "no".

Signed-off-by: Christian Ehrhardt 
---

 configure |   27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/configure b/configure
--- a/configure
+++ b/configure
@@ -951,13 +951,17 @@ if test "$kvm" = "yes" ; then
 if test "$kvm" = "yes" ; then
 cat > $TMPC <
-#if !defined(KVM_API_VERSION) || \
-KVM_API_VERSION < 12 || \
-KVM_API_VERSION > 12 || \
-!defined(KVM_CAP_USER_MEMORY) || \
-!defined(KVM_CAP_SET_TSS_ADDR) || \
-!defined(KVM_CAP_DESTROY_MEMORY_REGION_WORKS)
+#if !defined(KVM_API_VERSION) || KVM_API_VERSION < 12 || KVM_API_VERSION > 12
 #error Invalid KVM version
+#endif
+#if !defined(KVM_CAP_USER_MEMORY)
+#error Missing KVM capability KVM_CAP_USER_MEMORY
+#endif
+#if !defined(KVM_CAP_SET_TSS_ADDR)
+#error Missing KVM capability KVM_CAP_SET_TSS_ADDR
+#endif
+#if !defined(KVM_CAP_DESTROY_MEMORY_REGION_WORKS)
+#error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
 #endif
 int main(void) { return 0; }
 EOF
@@ -970,7 +974,16 @@ EOF
   > /dev/null 2>/dev/null ; then
 :
   else
-kvm="no"
+kvm="no";
+if [ -x "`which awk 2>/dev/null`" ] && \
+   [ -x "`which grep 2>/dev/null`" ]; then
+  kvmerr=`$cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $kvm_cflags $TMPC 2>&1 \
+	| grep "error: " \
+	| awk -F "error: " '{if (NR>1) printf(", "); printf("%s",$2);}'`
+  if test "$kvmerr" != "" ; then
+kvm="no - (${kvmerr})"
+  fi
+fi
   fi
 fi
 

[PATCH] kvm: userspace: change vtd.o to iommu.o in Kbuild for IA64

[Huang, Wei W]

vtd.c has been renamed to iommu.c, need to change it in Kbuild accordingly.

Signed-off-by: Wei Huang 
---
 kernel/ia64/Kbuild |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/kernel/ia64/Kbuild b/kernel/ia64/Kbuild
index 130ec45..ce3a47a 100644
--- a/kernel/ia64/Kbuild
+++ b/kernel/ia64/Kbuild
@@ -4,7 +4,7 @@ kvm-objs := kvm_main.o ioapic.o coalesced_mmio.o kvm-ia64.o 
kvm_fw.o \
irq_comm.o ../anon_inodes.o ../external-module-compat.o
 
 ifeq ($(CONFIG_DMAR),y)
-kvm-objs += vtd.o
+kvm-objs += iommu.o
 endif
 
 EXTRA_CFLAGS_vcpu.o += -mfixed-range=f2-f5,f12-f127
-- 
1.6.1.rc3


>-Original Message-
>From: Zhang, Xiantao
>Sent: 2009年1月9日 9:41
>To: Amit Shah; Huang, Wei W
>Cc: kvm
>Subject: RE: [PATCH] kvm: userspace: change vtd.o to iommu.o in Kbuild
>
>Amit Shah wrote:
>> On Thu, Jan 08, 2009 at 03:27:12PM +0800, Huang, Wei W wrote:
>>> vtd.c has been renamed to iommu.c, need to change it in Kbuild
>>> accordingly.
>>>
>>> Signed-off-by: Wei Huang 
>>> ---
>>>  kernel/x86/Kbuild |2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/kernel/x86/Kbuild b/kernel/x86/Kbuild
>>> index c4723b1..48339b4 100644
>>> --- a/kernel/x86/Kbuild
>>> +++ b/kernel/x86/Kbuild
>>> @@ -10,7 +10,7 @@ ifeq ($(EXT_CONFIG_KVM_TRACE),y)
>>>  kvm-objs += kvm_trace.o
>>>  endif
>>>  ifeq ($(CONFIG_DMAR),y)
>>> -kvm-objs += vtd.o
>>> +kvm-objs += iommu.o
>>
>> This won't be able to build an older kernel.
>
>Please also modify kernel/ia64/Kbuild together.  I don't think it breaks old
>kernels, because userspace build only adopts the latest kvm.git.
>Xiantao
>



0001-Change-vtd.o-to-iommu.o-in-Kbuild-for-IA64.patch
Description: 0001-Change-vtd.o-to-iommu.o-in-Kbuild-for-IA64.patch

[PATCH 1/1] KVM: x86: No wrap around for lapic timer

[Sheng Yang]

Or would we meet 585 years later? :)

Seriously, this wrap around hide implicit error...

Reminder by Alexander Graf.

Signed-off-by: Sheng Yang 
---
 arch/x86/kvm/lapic.c |   13 ++---
 1 files changed, 2 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index afac68c..87c1da5 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -524,18 +524,9 @@ static u32 apic_get_tmcct(struct kvm_lapic *apic)
if (tmcct == 0)
return 0;
 
-   if (unlikely(ktime_to_ns(now) <=
-   ktime_to_ns(apic->timer.last_update))) {
-   /* Wrap around */
-   passed = ktime_add(( {
-   (ktime_t) {
-   .tv64 = KTIME_MAX -
-   (apic->timer.last_update).tv64}; }
-  ), now);
-   apic_debug("time elapsed\n");
-   } else
-   passed = ktime_sub(now, apic->timer.last_update);
+   BUG_ON(ktime_to_ns(now) <= ktime_to_ns(apic->timer.last_update));
 
+   passed = ktime_sub(now, apic->timer.last_update);
counter_passed = div64_u64(ktime_to_ns(passed),
   (APIC_BUS_CYCLE_NS * 
apic->timer.divide_count));
 
-- 
1.5.4.5

--
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] Fix almost infinite loop in APIC

[Sheng Yang]

On Friday 09 January 2009 00:36:06 Alexander Graf wrote:
> While booting Linux in VMware ESX, I encountered a strange effect
> in the in-kernel lapic implementation: time went backwards!
>
> While this should never occur, because of that the while loop that
> is done after the invalid calculations caused my host system to hang.
>
> In order to make debugging easier, let's replace this as suggested
> with a modulo function and not run into the danger of looping forever.
>
> To replace the nice hint this bug gave me that the values are broken,
> I added a printk message so people encountering this can at least
> see that something is fishy.
>
> Of course, the real issue needs to be fixed as well! I'm open to ideas
> why now < last_update!
>
> (Thanks to Kevin for his help in debugging this)
>
> Signed-off-by: Alexander Graf 
> Signed-off-by: Kevin Wolf 
> ---

Hi Alexander

I'm a little suspect here:

>   if (unlikely(ktime_to_ns(now) <=
>   ktime_to_ns(apic->timer.last_update))) {
>   /* Wrap around */
>   passed = ktime_add(( {
>   (ktime_t) {
>   .tv64 = KTIME_MAX -
>   (apic->timer.last_update).tv64}; }
>  ), now);
>   apic_debug("time elapsed\n");
>   } else
>   passed = ktime_sub(now, apic->timer.last_update);

And now apic timer base is hr_timer with CLOCK_MONOTONIC, and get_time() is 
really ktime_get() which is almost impossible to wrap around. If it's 
overflow, at least we need a warning. I think this piece of code due to clock 
source change.

So I doubt: due to some reason, now <= apic->timer.last_update, which cause a 
big wrap around operation.

And the most suspect:

> void kvm_apic_timer_intr_post(struct kvm_vcpu *vcpu, int vec)
> {
>   struct kvm_lapic *apic = vcpu->arch.apic;
>
>   if (apic && apic_lvt_vector(apic, APIC_LVTT) == vec)
>   apic->timer.last_update = ktime_add_ns(
>   apic->timer.last_update,
>   apic->timer.period);
> }

Not sure what's happening, have you tried this? (In fact, I am little willing 
to replace all apic->timer.dev.base->get_time() with more explicit ktime_get() 
as in pit.)

--
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index afac68c..414e7e0 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1115,9 +1115,7 @@ void kvm_apic_timer_intr_post(struct kvm_vcpu *vcpu, int 
vec)
struct kvm_lapic *apic = vcpu->arch.apic;

if (apic && apic_lvt_vector(apic, APIC_LVTT) == vec)
-   apic->timer.last_update = ktime_add_ns(
-   apic->timer.last_update,
-   apic->timer.period);
+   apic->timer.last_update = apic->timer.dev.base->get_time();
 }

 int kvm_get_apic_interrupt(struct kvm_vcpu *vcpu)


-- 
regards
Yang, Sheng


--
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 6/7] KVM: Split IOAPIC structure

[Sheng Yang]

On Thursday 08 January 2009 23:27:21 Marcelo Tosatti wrote:
> On Thu, Jan 08, 2009 at 06:45:34PM +0800, Sheng Yang wrote:
> > Prepared for reuse ioapic_redir_entry for MSI.
>
> What is the disadvantage of dispatching the MSI interrupts to the vcpus
> via the IOAPIC? Pin shortage I can think of, but adding more IOAPIC's is
> possible (and wanted anyway for systems with insane amounts of net/block
> devices).
>
> That would avoid code duplication (might need to handle a few msi
> specific bits).

I think for current RH=1 implement, independence of IOAPIC is acceptable...

Indicated by "Redicection hint indication"(RH) bit, there are two mode that 
MSI would deliver: either use IOAPIC redirect table entry(RH=0), or redirect 
directly(RH=1). I implemented the later for now, and it's the most common way.  
Of course, delivery would go through IOAPIC when RH=0. 

-- 
regards
Yang, Sheng

--
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: qcow2 corruption?

[John Morrissey]

On Thu, Jan 08, 2009 at 02:33:28PM -0600, Anthony Liguori wrote:
> John Morrissey wrote:
> >I'm encountering what seems like disk corruption when using qcow2 images,
> >created with 'kvm-img create -f qcow2 image.qcow2 15G'.
> >
> >A simple test case is to use the Debian installer (I'm using the lenny
> >rc1 images from http://www.debian.org/devel/debian-installer/) to install
> >a new domain. The qcow2 file on disk grows due to the mkfs(8) activity,
> >then the installer faults while trying to mount the root filesystem
> >(Invalid argument). 'fdisk -l' shows that the partition table just
> >created by the installer is gone.
> 
> There are patches that touch the block layer.  Please try to reproduce 
> on vanilla kvm.  I don't trust the debian patches.

Couldn't reproduce this with Debian packaging minus its patch for
CVE-2008-0928 (taken from Fedora FWIW), which is the only one touching the
block layer.

Upon further scrutiny, I realized I pooched updating the patch for KVM 82.
The value for the BDRV_O_AUTOGROW constant introduced in that patch collides
with a new BDRV_ constant introduced between KVM 79 and 82. Changing the
constant's value (Fedora project has an updated patch, too) fixes this.

Ryan, this seems to fix the SCSI BUGging, too. I figure you won't want to
pursue that further?

Sorry for the bother, guys.

john
-- 
John Morrissey  _o/\   __o
j...@horde.net_-< \_  /  \     <  \,
www.horde.net/__(_)/_(_)/\___(_) /_(_)__
--
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/7] KVM: Add a route layer to convert MSI message to GSI

[Sheng Yang]

On Thursday 08 January 2009 23:08:25 Avi Kivity wrote:
> Sheng Yang wrote:
> > Avi's purpose, to use single kvm_set_irq() to deal with all interrupt,
> > including MSI. So here is it.
> >
> > struct gsi_route_entry is a mapping from a special gsi(with
> > KVM_GSI_MSG_MASK) to MSI/MSI-X message address/data. And the struct can
> > also be extended for other purpose.
> >
> > Now we support up to 256 gsi_route_entry mapping, and gsi is allocated by
> > kernel and provide two ioctls to userspace, which is more flexiable.
> >
> > @@ -553,4 +558,25 @@ struct kvm_assigned_irq {
> >  #define KVM_DEV_IRQ_ASSIGN_MSI_ACTION  KVM_DEV_IRQ_ASSIGN_ENABLE_MSI
> >  #define KVM_DEV_IRQ_ASSIGN_ENABLE_MSI  (1 << 0)
> >
> > +struct kvm_gsi_route_guest {
> > +   __u32 entries_nr;
>
> Need padding here otherwise offsetof(entries) will differ on 32-bit and
> 64-bit kernels.

OK.

>
> > +   struct kvm_gsi_route_entry_guest *entries;
>
> Like Marcelo says, zero sized array is better here.
>
> > +};
> > +
> > +#define KVM_GSI_ROUTE_MSI  (1 << 0)
>
> This looks like a flag.  Shouldn't it be a type?

Oh, custom... Would update.

> > +struct kvm_gsi_route_entry_guest {
>
> what does _guest mean here? almost all kvm stuff is _guest related.

Because I can't think of a good name... kvm_gsi_route_entry_guest? 
kvm_gsi_kernel_route_entry? What's your favorite? :)

> > +   __u32 gsi;
> > +   __u32 type;
> > +   __u32 flags;
> > +   __u32 reserved;
> > +   union {
> > +   struct {
> > +   __u32 addr_lo;
> > +   __u32 addr_hi;
> > +   __u32 data;
> > +   } msi;
> > +   __u32 padding[8];
> > +   };
> > +};
> > +
>
> Since we replace the entire table every time, how do ioapic/pic gsis work?
> >  /* The guest did something we don't support. */
> > @@ -336,6 +339,19 @@ void kvm_unregister_irq_mask_notifier(struct kvm
> > *kvm, int irq, struct kvm_irq_mask_notifier *kimn);
> >  void kvm_fire_mask_notifiers(struct kvm *kvm, int irq, bool mask);
> >
> > +#define KVM_GSI_ROUTE_MASK0x100ull
> > +struct kvm_gsi_route_entry {
> > +   u32 gsi;
> > +   u32 type;
> > +   u32 flags;
> > +   u32 reserved;
> > +   union {
> > +   struct msi_msg msi;
> > +   u32 reserved[8];
>
> No need for reserved fields in kernel data.

Yeah

> > +   };
> > +   struct hlist_node link;
> > +};
> > @@ -123,3 +123,73 @@ void kvm_fire_mask_notifiers(struct kvm *kvm, int
> > irq, bool mask) kimn->func(kimn, mask);
> >  }
> >
> > +int kvm_update_gsi_route(struct kvm *kvm, struct kvm_gsi_route_entry
> > *entry) +{
> > +   struct kvm_gsi_route_entry *found_entry, *new_entry;
> > +   int r, gsi;
> > +
> > +   mutex_lock(&kvm->lock);
> > +   /* Find whether we need a update or a new entry */
> > +   found_entry = kvm_find_gsi_route_entry(kvm, entry->gsi);
> > +   if (found_entry)
> > +   *found_entry = *entry;
> > +   else {
> > +   gsi = find_first_zero_bit(kvm->gsi_route_bitmap,
> > + KVM_NR_GSI_ROUTE_ENTRIES);
> > +   if (gsi >= KVM_NR_GSI_ROUTE_ENTRIES) {
> > +   r = -ENOSPC;
> > +   goto out;
> > +   }
> > +   new_entry = kzalloc(sizeof(*new_entry), GFP_KERNEL);
> > +   if (!new_entry) {
> > +   r = -ENOMEM;
> > +   goto out;
> > +   }
> > +   *new_entry = *entry;
> > +   entry->gsi = gsi | KVM_GSI_ROUTE_MASK;
> > +   __set_bit(gsi, kvm->gsi_route_bitmap);
> > +   hlist_add_head(&new_entry->link, &kvm->gsi_route_list);
> > +   }
> > +   r = 0;
> > +out:
> > +   mutex_unlock(&kvm->lock);
> > +   return r;
> > +}
>
> Why not throw everything and set the new table?

Userspace to maintain a big route table? Just for MSI/MSI-X it's easy, but for 
others, a global one is needed, and need follow up more maintain functions. 
For kernel, a little more effect can archive this, like this. So I do it in 
this way.

> I didn't see where you respond the new KVM_CAP.  It looks like a good
> place to return the maximum size of the table.

I just use it as #ifdef in userspace now, for no user other than MSI/MSI-X 
now. And if we keep maintaining it in kernel, we would return free size 
instead of maximum size..

-- 
regards
Yang, Sheng
--
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/7] KVM: Add a route layer to convert MSI message to GSI

[Sheng Yang]

On Thursday 08 January 2009 22:20:22 Marcelo Tosatti wrote:
> On Thu, Jan 08, 2009 at 06:45:29PM +0800, Sheng Yang wrote:
> >   * ioctls for VM fds
> > @@ -433,6 +436,8 @@ struct kvm_trace_rec {
> >  #define KVM_ASSIGN_IRQ _IOR(KVMIO, 0x70, \
> > struct kvm_assigned_irq)
> >  #define KVM_REINJECT_CONTROL  _IO(KVMIO, 0x71)
> > +#define KVM_REQUEST_GSI_ROUTE_IOWR(KVMIO, 0x72, void *)
> > +#define KVM_FREE_GSI_ROUTE   _IOR(KVMIO, 0x73, void *)
>
> Oh this slipped: should be struct kvm_gsi_route_guest.

Oh, yeah, forgot to change it back(I original purpose a array here...)
>
> >  /*
> >   * ioctls for vcpu fds
> > @@ -553,4 +558,25 @@ struct kvm_assigned_irq {
> >  #define KVM_DEV_IRQ_ASSIGN_MSI_ACTION  KVM_DEV_IRQ_ASSIGN_ENABLE_MSI
> >  #define KVM_DEV_IRQ_ASSIGN_ENABLE_MSI  (1 << 0)
> >
> > +struct kvm_gsi_route_guest {
> > +   __u32 entries_nr;
> > +   struct kvm_gsi_route_entry_guest *entries;
> > +};
>
> And you can use a zero sized array here.

OK.
>
> Sorry :(

Oh, that's not necessary. :)

-- 
regards
Yang, Sheng

--
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] kvm: userspace: change vtd.o to iommu.o in Kbuild

[Zhang, Xiantao]

Amit Shah wrote:
> On Thu, Jan 08, 2009 at 03:27:12PM +0800, Huang, Wei W wrote:
>> vtd.c has been renamed to iommu.c, need to change it in Kbuild
>> accordingly. 
>> 
>> Signed-off-by: Wei Huang 
>> ---
>>  kernel/x86/Kbuild |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>> 
>> diff --git a/kernel/x86/Kbuild b/kernel/x86/Kbuild
>> index c4723b1..48339b4 100644
>> --- a/kernel/x86/Kbuild
>> +++ b/kernel/x86/Kbuild
>> @@ -10,7 +10,7 @@ ifeq ($(EXT_CONFIG_KVM_TRACE),y)
>>  kvm-objs += kvm_trace.o
>>  endif
>>  ifeq ($(CONFIG_DMAR),y)
>> -kvm-objs += vtd.o
>> +kvm-objs += iommu.o
> 
> This won't be able to build an older kernel.

Please also modify kernel/ia64/Kbuild together.  I don't think it breaks old 
kernels, because userspace build only adopts the latest kvm.git.  
Xiantao


--
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] kvm: userspace: change vtd.o to iommu.o in Kbuild

[Han, Weidong]

Amit Shah wrote:
> On Thu, Jan 08, 2009 at 03:27:12PM +0800, Huang, Wei W wrote:
>> vtd.c has been renamed to iommu.c, need to change it in Kbuild
>> accordingly. 
>> 
>> Signed-off-by: Wei Huang 
>> ---
>>  kernel/x86/Kbuild |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>> 
>> diff --git a/kernel/x86/Kbuild b/kernel/x86/Kbuild
>> index c4723b1..48339b4 100644
>> --- a/kernel/x86/Kbuild
>> +++ b/kernel/x86/Kbuild
>> @@ -10,7 +10,7 @@ ifeq ($(EXT_CONFIG_KVM_TRACE),y)
>>  kvm-objs += kvm_trace.o
>>  endif
>>  ifeq ($(CONFIG_DMAR),y)
>> -kvm-objs += vtd.o
>> +kvm-objs += iommu.o
> 
> This won't be able to build an older kernel.
> 

Because IOMMU APIs were changed in kernel, it needs external module to support 
older kernel.

Regards,
Weidong

> Amit

--
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: KVM: Merge MSI handling to kvm_set_irq

[Sheng Yang]

On Thursday 08 January 2009 21:54:41 Mike Day wrote:
> On 07/01/09 18:42 +0800, Sheng Yang wrote:
> > Using kvm_set_irq to handle all interrupt injection.
> >
> > Signed-off-by: Sheng Yang 
> > ---
> >
> > +static void gsi_dispatch(struct kvm *kvm, u32 gsi)
>
> ...
>
> > +   case IOAPIC_FIXED:
> > +   for (vcpu_id = 0; deliver_bitmask != 0; vcpu_id++) {
> > +   if (!(deliver_bitmask & (1 << vcpu_id)))
> > +   continue;
> > +   deliver_bitmask &= ~(1 << vcpu_id);
> > +   vcpu = ioapic->kvm->vcpus[vcpu_id];
> > +   if (vcpu)
> > +   kvm_apic_set_irq(vcpu, vector,
> > +   trig_mode);
> > +   }
> > +   break;
> > +   default:
> > +   break;
> > +   }
>
> In cases such as the for() loop above, which are numerous in the
> patchset, I wonder if using bitops would be slightly better:
>
>   case IOAPIC_FIXED:
>   while (deliver_bitmask != 0) {
>   vcpu_id = ffs(deliver_bitmask);
>   __clear_bit(vcpu_id - 1, &deliver_bitmask);
>   vcpu = ioapic->kvm->vcpus[vcpu_id - 1];
>   if (vcpu)
>   kvm_apic_set_irq(vcpu, vector,
>trig_mode);
>   } ;
>
>
> I did a quick check and the second example compiles to a more
> consise set of assembler instructions. The current code uses bitops in
> cases like this.
>

Yes, that's what I did for bitmap changing in the following patches. Please 
refer to "[PATCH 10/10] KVM: bit ops for deliver_bitmap" I sent before.

-- 
regards
Yang, Sheng

> Mike

--
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

[ kvm-Bugs-2494730 ] Guests "stalling" on kvm-82

[SourceForge.net]

Bugs item #2494730, was opened at 2009-01-09 09:59
Message generated for change (Comment added) made by kmshanah
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2494730&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kevin Shanahan (kmshanah)
Assigned to: Nobody/Anonymous (nobody)
Summary: Guests "stalling" on kvm-82

Initial Comment:
I am seeing periodic stalls in Linux and Windows guests with kvm-82 on an IBM 
X3550 server with 2 x Xeon 5130 CPUs and 32GB RAM.

I am *reasonably* certain that this is a regression somewhere between kvm-72 
and kvm-82. We had been running kvm-72 (actually, the debian kvm-source 
package) up until now and never noticed the problem. Now the stalls are very 
obvious. When the guest stalls, the at least one kvm process on the host 
gobbles up 100% CPU. I'll do my debugging with the Linux guest, as that's sure 
to be easier to deal with.

As a simple demostration that the guest is unresponsive, here is the result of 
me pinging the guest from another machine on the (very quiet) LAN:

--- hermes-old.wumi.org.au ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 599659ms
rtt min/avg/max/mdev = 0.255/181.211/6291.871/558.706 ms, pipe 7

The latency varies pretty badly, with spikes up to several seconds as you can 
see.

The problem is not reproducable on other VT capable hardware that I have - e.g. 
my desktop has a E8400 CPU which runs the VMs just fine. Does knowing that make 
it any easier to guess where the problem might be?

The Xeon 5130 does not have the "smx", "est", "sse4_1", "xsave", "vnmi" and 
"flexpriority" CPU flags that the E8400 does.

Because this server is the only hardware I have which exhibits the problem and 
it's a production machine, I have limited times where I can do testing. 
However, I will try confirm that kvm-72 is okay and then bisect.

Currently the host is running a 2.6.28 kernel with the kvm-82 modules. I guess 
I'm likely to have problems compiling the older kvm releases against this 
kernel, so I'll have to drop back to 2.6.27.something to run the tests.

CPU Vendor: Intel
CPU Type: Xeon 5130
Number of CPUs: 2
Host distribution: Debain Lenny/Sid
KVM version: kvm-82
Host kernel: Linux 2.6.28 x86_64
Guest Distribution: Debian Etch
Guest kernel: Linux 2.6.27.10 i686

Host's /proc/cpuinfo:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Xeon(R) CPU5130  @ 2.00GHz
stepping: 6
cpu MHz : 1995.117
cache size  : 4096 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx tm2 
ssse3 cx16 xtpr pdcm dca lahf_lm tpr_shadow
bogomips: 3990.23
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Xeon(R) CPU5130  @ 2.00GHz
stepping: 6
cpu MHz : 1995.117
cache size  : 4096 KB
physical id : 0
siblings: 2
core id : 1
cpu cores   : 2
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx tm2 
ssse3 cx16 xtpr pdcm dca lahf_lm tpr_shadow
bogomips: 3989.96
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Xeon(R) CPU5130  @ 2.00GHz
stepping: 6
cpu MHz : 1995.117
cache size  : 4096 KB
physical id : 3
siblings: 2
core id : 0
cpu cores   : 2
apicid  : 6
initial apicid  : 6
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx tm2 
ssse3 cx16 xtpr pdcm dca lahf_lm t

Re: [PATCH] KVM: MMU: Segregate mmu pages created with different cr4.pge settings

[Marcelo Tosatti]

On Thu, Jan 08, 2009 at 08:53:21PM +0100, Alexander Graf wrote:
> Sorry for the late reply - I wanted to know who kvm hangs in the host  
> kernel context :)
>
> On 07.01.2009, at 14:46, Marcelo Tosatti  wrote:
>
>> On Wed, Jan 07, 2009 at 01:32:41PM +0200, Avi Kivity wrote:
>>> Marcelo Tosatti wrote:
 Let me shoot at one direction: a shadow page with PGE bit in either
 state is created. Later that shadow page is nuked (via mmu  
 notifiers,
 for example).
>>>
>>> I doubt that mmu notifiers were invoked in this case (the bug would  
>>> be
>>> very rare); in any case we flush the tlb.
>>
>> This comment is worrying
>>
>>/*
>> * FIXME: Tis shouldn't be necessary here, but there is a flush
>> * missing in the MMU code. Until we find this bug, flush the
>> * complete TLB here on an NPF
>> */
>>if (npt_enabled)
>>svm_flush_tlb(&svm->vcpu);
>>
>
> This is in, because netbench in an npt-guest failed after a few minutes 
> (see Alex W's bug report) and this appeard to fix it.

Right. The comment is scary, thats all. Maybe the hypothetical missing
flush is also the cause for this bug you're not. Or not.

>> Alexander, you might want to try this patch, -ENONPT here (and revert 
>> the previous
>> one).
>
> Eh, what?

I meant I have no NPT box to test myself easily.

"revert the previous one" = remove the !tdp_enabled test on set_cr4.

The patch below is just a hack to flush the TLB of remote vcpu's before
updating the host TLB. To confirm an experimental theory (read: guess).

Hum, NPT is surely not available inside the guest for ESX to use?

Yeah, gathering more information would be helpful.

>> I have no clue, what else could be causing this?
>>
>> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
>> index 10bdb2a..bf68e5b 100644
>> --- a/arch/x86/kvm/mmu.c
>> +++ b/arch/x86/kvm/mmu.c
>> @@ -33,6 +33,7 @@
>> #include 
>> #include 
>> #include 
>> +#include 
>>
>> /*
>>  * When setting this variable to true it enables Two-Dimensional- 
>> Paging
>> @@ -1850,6 +1851,11 @@ static int __direct_map(struct kvm_vcpu *vcpu, 
>> gpa_t v, int write,
>>
>>if (*iterator.sptep == shadow_trap_nonpresent_pte) {
>>pseudo_gfn = (iterator.addr & PT64_DIR_BASE_ADDR_MASK) >>  
>> PAGE_SHIFT;
>> +
>> +kvm_flush_remote_tlbs(vcpu->kvm);
>> +kvm_mmu_flush_tlb(vcpu);
>> +__flush_tlb();
>> +
>>sp = kvm_mmu_get_page(vcpu, pseudo_gfn, iterator.addr,
>>  iterator.level - 1,
>>  1, ACC_ALL, iterator.sptep);
>> --
>> 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
--
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

[ kvm-Bugs-2494730 ] Guests "stalling" on kvm-82

[SourceForge.net]

Bugs item #2494730, was opened at 2009-01-09 09:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2494730&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kevin Shanahan (kmshanah)
Assigned to: Nobody/Anonymous (nobody)
Summary: Guests "stalling" on kvm-82

Initial Comment:
I am seeing periodic stalls in Linux and Windows guests with kvm-82 on an IBM 
X3550 server with 2 x Xeon 5130 CPUs and 32GB RAM.

I am *reasonably* certain that this is a regression somewhere between kvm-72 
and kvm-82. We had been running kvm-72 (actually, the debian kvm-source 
package) up until now and never noticed the problem. Now the stalls are very 
obvious. When the guest stalls, the at least one kvm process on the host 
gobbles up 100% CPU. I'll do my debugging with the Linux guest, as that's sure 
to be easier to deal with.

As a simple demostration that the guest is unresponsive, here is the result of 
me pinging the guest from another machine on the (very quiet) LAN:

--- hermes-old.wumi.org.au ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 599659ms
rtt min/avg/max/mdev = 0.255/181.211/6291.871/558.706 ms, pipe 7

The latency varies pretty badly, with spikes up to several seconds as you can 
see.

The problem is not reproducable on other VT capable hardware that I have - e.g. 
my desktop has a E8400 CPU which runs the VMs just fine. Does knowing that make 
it any easier to guess where the problem might be?

The Xeon 5130 does not have the "smx", "est", "sse4_1", "xsave", "vnmi" and 
"flexpriority" CPU flags that the E8400 does.

Because this server is the only hardware I have which exhibits the problem and 
it's a production machine, I have limited times where I can do testing. 
However, I will try confirm that kvm-72 is okay and then bisect.

Currently the host is running a 2.6.28 kernel with the kvm-82 modules. I guess 
I'm likely to have problems compiling the older kvm releases against this 
kernel, so I'll have to drop back to 2.6.27.something to run the tests.

CPU Vendor: Intel
CPU Type: Xeon 5130
Number of CPUs: 2
Host distribution: Debain Lenny/Sid
KVM version: kvm-82
Host kernel: Linux 2.6.28 x86_64
Guest Distribution: Debian Etch
Guest kernel: Linux 2.6.27.10 i686

Host's /proc/cpuinfo:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Xeon(R) CPU5130  @ 2.00GHz
stepping: 6
cpu MHz : 1995.117
cache size  : 4096 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx tm2 
ssse3 cx16 xtpr pdcm dca lahf_lm tpr_shadow
bogomips: 3990.23
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Xeon(R) CPU5130  @ 2.00GHz
stepping: 6
cpu MHz : 1995.117
cache size  : 4096 KB
physical id : 0
siblings: 2
core id : 1
cpu cores   : 2
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx tm2 
ssse3 cx16 xtpr pdcm dca lahf_lm tpr_shadow
bogomips: 3989.96
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 2
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Xeon(R) CPU5130  @ 2.00GHz
stepping: 6
cpu MHz : 1995.117
cache size  : 4096 KB
physical id : 3
siblings: 2
core id : 0
cpu cores   : 2
apicid  : 6
initial apicid  : 6
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx tm2 
ssse3 cx16 xtpr pdc

Re: [PATCH] qemu: report issues causing the kvm probe to fail v3

[Anthony Liguori]

ehrha...@linux.vnet.ibm.com wrote:

From: Christian Ehrhardt 

The patch applies to upstream qemu as well as kvm-userspace, but since it is
the qemu configure script I think it should go to upstream qemu (Anthony)
first and with the next merge to kvm-userspace. On the other hand it is the kvm
probe so an ack from Avi in case v3 is ok would be reasonable.

*updates*
v2 - it also reports other errors than just #error preprocessor statements
 (requested by Avi)
v3 - In case awk or grep is not installed it now gracfully (silently)
 fails still disabling kvm (requested by Anthony)

This patch is about reporting more details of the issue if configuring kvm
fails. Therefore this patch keeps the qemu style configure output which is a
list of "$Feature $Status", but extend the "no" result like "KVM Support no"
with some more information.

There might be a lot of things going wrong with that probe and I don't want
to handle all of them, but if it is one of the known checks e.g. for
KVM_API_VERSION then we could grep/awk that out and report it. The patch
reports in case of a known case in the style
"KVM support no - (Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS)"

In case more than one #error is triggered it creates a comma separated list in
those brackets and in case it is something else than an #error it just reports
plain old "no".

Signed-off-by: Christian Ehrhardt 
---

 configure |   27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/qemu/configure b/qemu/configure
--- a/qemu/configure
+++ b/qemu/configure
  


Please send against upstream QEMU.

Regards,

Anthony Liguori

--
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: qcow2 corruption?

[Anthony Liguori]

John Morrissey wrote:

I'm encountering what seems like disk corruption when using qcow2 images,
created with 'kvm-img create -f qcow2 image.qcow2 15G'.

A simple test case is to use the Debian installer (I'm using the lenny rc1
images from http://www.debian.org/devel/debian-installer/) to install a new
domain. The qcow2 file on disk grows due to the mkfs(8) activity, then the
installer faults while trying to mount the root filesystem (Invalid
argument). 'fdisk -l' shows that the partition table just created by the
installer is gone.

In a few cases, I've managed to finish an installation, but the resulting
filesystem is strangely corrupt:

# file /usr/bin/w.procps
/usr/bin/w.procps: gzip compressed data, was "aptitude.8", from Unix, last 
modified: Wed Mar 14 14:11:18 2007, max compression

I've tried with the Debian packaging of KVM 79 and 82; both exhibit the same
behavior (disclaimer: Debian has about a dozen patches in their kvm
packaging, but they all seem to be changes to the build/install process or
security-related). Host running KVM is up-to-date Debian lenny
(64-bit/amd64) running kernel 2.6.26 (Debian linux-image-2.6.26-1-amd64
2.6.26-12).
  


There are patches that touch the block layer.  Please try to reproduce 
on vanilla kvm.  I don't trust the debian patches.


Regards,

Anthony Liguori


john
  


--
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: qcow2 corruption?

[John Morrissey]

On Thu, Jan 08, 2009 at 02:10:31PM -0600, Ryan Harper wrote:
> * John Morrissey  [2009-01-08 13:28]:
> > I'm encountering what seems like disk corruption when using qcow2 images,
> > created with 'kvm-img create -f qcow2 image.qcow2 15G'.
> 
> using ide or scsi as your block device?

IDE.

> > A simple test case is to use the Debian installer (I'm using the lenny
> > rc1 images from http://www.debian.org/devel/debian-installer/) to
> > install a new domain. The qcow2 file on disk grows due to the mkfs(8)
> > activity, then the installer faults while trying to mount the root
> > filesystem (Invalid argument). 'fdisk -l' shows that the partition table
> > just created by the installer is gone.
> > 
> > In a few cases, I've managed to finish an installation, but the resulting
> > filesystem is strangely corrupt:
> > 
> > # file /usr/bin/w.procps
> > /usr/bin/w.procps: gzip compressed data, was "aptitude.8", from Unix, last 
> > modified: Wed Mar 14 14:11:18 2007, max compression
> 
> If you are using ide and getting corruption, try again but with creating
> a disk image with the raw format: 
> 
> qemu-img create -f raw  
> 
> That should help track down where the corruption is coming from.

raw images are fine. (Sorry, should've mentioned that in the first place.)

john
-- 
John Morrissey  _o/\   __o
j...@horde.net_-< \_  /  \     <  \,
www.horde.net/__(_)/_(_)/\___(_) /_(_)__
--
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: qcow2 corruption?

[Ryan Harper]

* John Morrissey  [2009-01-08 13:28]:
> I'm encountering what seems like disk corruption when using qcow2 images,
> created with 'kvm-img create -f qcow2 image.qcow2 15G'.
> 

using ide or scsi as your block device?

> A simple test case is to use the Debian installer (I'm using the lenny rc1
> images from http://www.debian.org/devel/debian-installer/) to install a new
> domain. The qcow2 file on disk grows due to the mkfs(8) activity, then the
> installer faults while trying to mount the root filesystem (Invalid
> argument). 'fdisk -l' shows that the partition table just created by the
> installer is gone.
> 
> In a few cases, I've managed to finish an installation, but the resulting
> filesystem is strangely corrupt:
> 
> # file /usr/bin/w.procps
> /usr/bin/w.procps: gzip compressed data, was "aptitude.8", from Unix, last 
> modified: Wed Mar 14 14:11:18 2007, max compression

If you are using ide and getting corruption, try again but with creating
a disk image with the raw format: 

qemu-img create -f raw  

That should help track down where the corruption is coming from.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.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] KVM: MMU: Segregate mmu pages created with different cr4.pge settings

[Alexander Graf]

Sorry for the late reply - I wanted to know who kvm hangs in the host  
kernel context :)


On 07.01.2009, at 14:46, Marcelo Tosatti  wrote:


On Wed, Jan 07, 2009 at 01:32:41PM +0200, Avi Kivity wrote:

Marcelo Tosatti wrote:

Let me shoot at one direction: a shadow page with PGE bit in either
state is created. Later that shadow page is nuked (via mmu  
notifiers,

for example).


I doubt that mmu notifiers were invoked in this case (the bug would  
be

very rare); in any case we flush the tlb.


This comment is worrying

   /*
* FIXME: Tis shouldn't be necessary here, but there is a flush
* missing in the MMU code. Until we find this bug, flush the
* complete TLB here on an NPF
*/
   if (npt_enabled)
   svm_flush_tlb(&svm->vcpu);



This is in, because netbench in an npt-guest failed after a few  
minutes (see Alex W's bug report) and this appeard to fix it.



Alexander, you might want to try this patch, -ENONPT here (and  
revert the previous

one).


Eh, what?


I have no clue, what else could be causing this?

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 10bdb2a..bf68e5b 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -33,6 +33,7 @@
#include 
#include 
#include 
+#include 

/*
 * When setting this variable to true it enables Two-Dimensional- 
Paging
@@ -1850,6 +1851,11 @@ static int __direct_map(struct kvm_vcpu  
*vcpu, gpa_t v, int write,


   if (*iterator.sptep == shadow_trap_nonpresent_pte) {
   pseudo_gfn = (iterator.addr & PT64_DIR_BASE_ADDR_MASK) >>  
PAGE_SHIFT;

+
+kvm_flush_remote_tlbs(vcpu->kvm);
+kvm_mmu_flush_tlb(vcpu);
+__flush_tlb();
+
   sp = kvm_mmu_get_page(vcpu, pseudo_gfn, iterator.addr,
 iterator.level - 1,
 1, ACC_ALL, iterator.sptep);
--
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

--
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

KVM: MMU: drop zeroing on mmu_memory_cache_alloc

[Marcelo Tosatti]

Zeroing on mmu_memory_cache_alloc is unnecessary since:

- Smaller areas are pre-allocated with kmem_cache_zalloc.
- Page pointed by ->spt is overwritten with prefetch_page 
  and entries in page pointed by ->gfns are initialized 
  before reading.

[avi: zeroing pages is unnecessary]

Signed-off-by: Marcelo Tosatti 

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 10bdb2a..823d0cd 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -352,7 +352,6 @@ static void *mmu_memory_cache_alloc(struct 
kvm_mmu_memory_cache *mc,
 
BUG_ON(!mc->nobjs);
p = mc->objects[--mc->nobjs];
-   memset(p, 0, size);
return p;
 }
 

--
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

qcow2 corruption?

[John Morrissey]

I'm encountering what seems like disk corruption when using qcow2 images,
created with 'kvm-img create -f qcow2 image.qcow2 15G'.

A simple test case is to use the Debian installer (I'm using the lenny rc1
images from http://www.debian.org/devel/debian-installer/) to install a new
domain. The qcow2 file on disk grows due to the mkfs(8) activity, then the
installer faults while trying to mount the root filesystem (Invalid
argument). 'fdisk -l' shows that the partition table just created by the
installer is gone.

In a few cases, I've managed to finish an installation, but the resulting
filesystem is strangely corrupt:

# file /usr/bin/w.procps
/usr/bin/w.procps: gzip compressed data, was "aptitude.8", from Unix, last 
modified: Wed Mar 14 14:11:18 2007, max compression

I've tried with the Debian packaging of KVM 79 and 82; both exhibit the same
behavior (disclaimer: Debian has about a dozen patches in their kvm
packaging, but they all seem to be changes to the build/install process or
security-related). Host running KVM is up-to-date Debian lenny
(64-bit/amd64) running kernel 2.6.26 (Debian linux-image-2.6.26-1-amd64
2.6.26-12).

john
-- 
John Morrissey  _o/\   __o
j...@horde.net_-< \_  /  \     <  \,
www.horde.net/__(_)/_(_)/\___(_) /_(_)__
--
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 2/3] kvm: qemu: handle link status in qemu_sendv_packet()

[Mark McLoughlin]

On Tue, 2008-12-09 at 08:57 -0600, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > Signed-off-by: Mark McLoughlin 
> > ---
> >  qemu/net.c |   18 +-
> >  1 files changed, 17 insertions(+), 1 deletions(-)
> >
> > diff --git a/qemu/net.c b/qemu/net.c
> > index 16a0990..f23a17f 100644
> > --- a/qemu/net.c
> > +++ b/qemu/net.c
> > @@ -400,6 +400,17 @@ static ssize_t vc_sendv_compat(VLANClientState *vc, 
> > const struct iovec *iov,
> >  return offset;
> >  }
> >  
> > +static ssize_t calc_iov_length(const struct iovec *iov, int iovcnt)
> > +{
> > +size_t offset = 0;
> > +int i;
> > +
> > +for (i = 0; i < iovcnt; i++)
> > +   offset += iov[i].iov_len;
> > +
> > +return offset;
> > +}
> > +
> >  ssize_t qemu_sendv_packet(VLANClientState *vc1, const struct iovec *iov,
> >   int iovcnt)
> >  {
> > @@ -407,13 +418,18 @@ ssize_t qemu_sendv_packet(VLANClientState *vc1, const 
> > struct iovec *iov,
> >  VLANClientState *vc;
> >  ssize_t max_len = 0;
> >  
> > +if (vc1->link_down)
> > +   return calc_iov_length(iov, iovcnt);
> > +
> >  for (vc = vlan->first_client; vc != NULL; vc = vc->next) {
> > ssize_t len = 0;
> >  
> > if (vc == vc1)
> > continue;
> >  
> > -   if (vc->fd_readv)
> > +   if (vc->link_down)
> > +   len = calc_iov_length(iov, iovcnt);
> >   
> 
> Instead of returning a success and silently dropping the packet, maybe 
> it would be better to return an error and let the card deal with 
> dropping the packet.
> 
> In real hardware, the link down would mean the TX queue would fill up 
> because packets aren't able to be sent.

I failed to figure out for real what typical hardware would do, e.g. by
reading the e1000 spec, but I figure the current behaviour is good
enough for now?

Re-based patches follow.

Cheers,
Mark.

--
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: KVM: MMU: zero caches before entering mmu_lock protected section

[Avi Kivity]

Marcelo Tosatti wrote:

Clean the pre-allocated cache pages before entering mmu_lock region.
This is safe since the caches are per-vcpu.

Smaller chunks are already zeroed by kmem_cache_zalloc.

~= 0.90% reduction in system time with AIM7 on RHEL3 / 4-vcpu.

Signed-off-by: Marcelo Tosatti 

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 10bdb2a..823d0cd 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -301,7 +301,7 @@ static int mmu_topup_memory_cache_page(struct 
kvm_mmu_memory_cache *cache,
if (cache->nobjs >= min)
return 0;
while (cache->nobjs < ARRAY_SIZE(cache->objects)) {
-   page = alloc_page(GFP_KERNEL);
+   page = alloc_page(GFP_KERNEL|__GFP_ZERO);
if (!page)
return -ENOMEM;
set_page_private(page, 0);
@@ -352,7 +352,6 @@ static void *mmu_memory_cache_alloc(struct 
kvm_mmu_memory_cache *mc,
 
 	BUG_ON(!mc->nobjs);

p = mc->objects[--mc->nobjs];
-   memset(p, 0, size);
return p;
 }
 
  


I think we can drop the memset altogether, since we will clear the page 
in ->prefetch_page() anyway.



--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
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

KVM: MMU: zero caches before entering mmu_lock protected section

[Marcelo Tosatti]

Clean the pre-allocated cache pages before entering mmu_lock region.
This is safe since the caches are per-vcpu.

Smaller chunks are already zeroed by kmem_cache_zalloc.

~= 0.90% reduction in system time with AIM7 on RHEL3 / 4-vcpu.

Signed-off-by: Marcelo Tosatti 

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 10bdb2a..823d0cd 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -301,7 +301,7 @@ static int mmu_topup_memory_cache_page(struct 
kvm_mmu_memory_cache *cache,
if (cache->nobjs >= min)
return 0;
while (cache->nobjs < ARRAY_SIZE(cache->objects)) {
-   page = alloc_page(GFP_KERNEL);
+   page = alloc_page(GFP_KERNEL|__GFP_ZERO);
if (!page)
return -ENOMEM;
set_page_private(page, 0);
@@ -352,7 +352,6 @@ static void *mmu_memory_cache_alloc(struct 
kvm_mmu_memory_cache *mc,
 
BUG_ON(!mc->nobjs);
p = mc->objects[--mc->nobjs];
-   memset(p, 0, size);
return p;
 }
 
--
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: BUG() with SCSI-interfaced disk images

[John Morrissey]

On Thu, Jan 08, 2009 at 08:01:03AM -0600, Ryan Harper wrote:
> I don't need the vmdk, but if there is some other repeatable process
> that can trigger this for you, getting that will allow me to recreate
> the issue myself.  For example, installing Debian into a vmdk, reboot,
> and then fsck'ing from inside the vm would trigger it.  Finding some
> sort of repeatable process that can trip the bug but without using any
> of your specific data would be the best way to move forward with the
> bug.

I can reproduce this when installing Debian lenny i386 (using the lenny rc1
install images from http://www.debian.org/devel/debian-installer/). The
installer will complain of I/O problems when trying to mkfs(8) the
filesystem and will prompt you to retry/ignore. Shortly thereafter, the
domain kernel panics.

Attached is the libvirt configuration; it's pretty straightforward and
translates into this kvm(1) invocation:

/usr/bin/kvm -S -M pc -m 512 -smp 1 -name scsi -monitor pty -boot n \
-drive file=/var/lib/libvirt/images/scsi.qcow,if=scsi,index=0 \
-net nic,macaddr=02:00:00:4d:58:13,vlan=0,model=e1000 \
-net tap,fd=11,script=,vlan=0,ifname=vnet0 \
-net nic,macaddr=02:00:00:23:7f:3d,vlan=1,model=e1000 \
-net tap,fd=13,script=,vlan=1,ifname=vnet1 \
-serial pty -parallel none -usb -vnc 0.0.0.0:0

john
-- 
John Morrissey  _o/\   __o
j...@horde.net_-< \_  /  \     <  \,
www.horde.net/__(_)/_(_)/\___(_) /_(_)__


scsi.xml
Description: XML document

Re: KVM-82 failed to compile

[Simon Gao]

Nikola Ciprich wrote:
> Hi,
> enable KVM support on kernel against which You're compiling..
> n.
>
>   
That did it. So from 2.6.27 and on, we need to enable KVM module in
kernel no matter we want to use a separate outside module or not. This
is a little strange.





--
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

[ kvm-Bugs-2386363 ] virtio-net doesn't set vc->info_str

[SourceForge.net]

Bugs item #2386363, was opened at 2008-12-03 19:43
Message generated for change (Comment added) made by sf-nolan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2386363&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: qemu
Group: None
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nolan (sf-nolan)
Assigned to: Nobody/Anonymous (nobody)
Summary: virtio-net doesn't set vc->info_str

Initial Comment:
Which makes "info network" not show the devices, which makes it difficult to 
figure out what NIC model a running VM is using via the monitor.

The fix is simple, just add the following to virtio-net.c::virtio_net_init 
right after the call to qemu_new_vlan_client:
 snprintf(n->vc->info_str, sizeof(n->vc->info_str),
  "%s macaddr=%02x:%02x:%02x:%02x:%02x:%02x", "virtio",
  n->nd->macaddr[0], n->nd->macaddr[1], n->nd->macaddr[2],
  n->nd->macaddr[3], n->nd->macaddr[4], n->nd->macaddr[5]);
Note that the string should probably be "virtio" not "virtio-net" so that it 
matches the model= command line parameter.

Ideally all of this should be factored up into qemu's generic network code, but 
the trivial change above at least brings virtio-net to parity with all the 
other NIC models.

--

>Comment By: Nolan (sf-nolan)
Date: 2009-01-08 09:45

Message:
I'm not sure that this should be closed, as I believe the
qemu_format_nic_info_str fix introduces a regression:
With this change, the "info network" command no longer lists the model,
making it impossible for monitor clients to determine the NIC model in use
for a given interface.

--

Comment By: Mark McLoughlin (markmc)
Date: 2009-01-08 09:38

Message:
Thanks, fixed in latest git:

http://git.kernel.org/?p=linux/kernel/git/avi/kvm-userspace.git;a=commitdiff;h=ca1fb16ab

--

Comment By: Hollis (hollis)
Date: 2008-12-12 08:31

Message:
Patch submitted: http://marc.info/?l=kvm&m=122882041418031&w=4

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2386363&group_id=180599
--
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

[ kvm-Bugs-2386363 ] virtio-net doesn't set vc->info_str

[SourceForge.net]

Bugs item #2386363, was opened at 2008-12-04 03:43
Message generated for change (Comment added) made by markmc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2386363&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: qemu
Group: None
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Nolan (sf-nolan)
Assigned to: Nobody/Anonymous (nobody)
Summary: virtio-net doesn't set vc->info_str

Initial Comment:
Which makes "info network" not show the devices, which makes it difficult to 
figure out what NIC model a running VM is using via the monitor.

The fix is simple, just add the following to virtio-net.c::virtio_net_init 
right after the call to qemu_new_vlan_client:
 snprintf(n->vc->info_str, sizeof(n->vc->info_str),
  "%s macaddr=%02x:%02x:%02x:%02x:%02x:%02x", "virtio",
  n->nd->macaddr[0], n->nd->macaddr[1], n->nd->macaddr[2],
  n->nd->macaddr[3], n->nd->macaddr[4], n->nd->macaddr[5]);
Note that the string should probably be "virtio" not "virtio-net" so that it 
matches the model= command line parameter.

Ideally all of this should be factored up into qemu's generic network code, but 
the trivial change above at least brings virtio-net to parity with all the 
other NIC models.

--

>Comment By: Mark McLoughlin (markmc)
Date: 2009-01-08 17:38

Message:
Thanks, fixed in latest git:

http://git.kernel.org/?p=linux/kernel/git/avi/kvm-userspace.git;a=commitdiff;h=ca1fb16ab

--

Comment By: Hollis (hollis)
Date: 2008-12-12 16:31

Message:
Patch submitted: http://marc.info/?l=kvm&m=122882041418031&w=4

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2386363&group_id=180599
--
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

[PATCH] Fix almost infinite loop in APIC

[Alexander Graf]

While booting Linux in VMware ESX, I encountered a strange effect
in the in-kernel lapic implementation: time went backwards!

While this should never occur, because of that the while loop that
is done after the invalid calculations caused my host system to hang.

In order to make debugging easier, let's replace this as suggested
with a modulo function and not run into the danger of looping forever.

To replace the nice hint this bug gave me that the values are broken,
I added a printk message so people encountering this can at least
see that something is fishy.

Of course, the real issue needs to be fixed as well! I'm open to ideas
why now < last_update!

(Thanks to Kevin for his help in debugging this)

Signed-off-by: Alexander Graf 
Signed-off-by: Kevin Wolf 
---
 arch/x86/kvm/lapic.c |   17 +
 1 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index afac68c..737217b 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -539,19 +539,20 @@ static u32 apic_get_tmcct(struct kvm_lapic *apic)
counter_passed = div64_u64(ktime_to_ns(passed),
   (APIC_BUS_CYCLE_NS * 
apic->timer.divide_count));
 
+   if (counter_passed > 0x7f00) {
+   /* If we're in here we probably encountered a bug! */
+   printk(KERN_INFO "LAPIC: Too high counter_passed value: "
+"0x%lx | 0x%lx (0x%lx) | 0x%lx (0x%lx)\n",
+counter_passed, ktime_to_ns(passed), passed,
+now.tv64, apic->timer.last_update.tv64);
+   }
+
if (counter_passed > tmcct) {
if (unlikely(!apic_lvtt_period(apic))) {
/* one-shot timers stick at 0 until reset */
tmcct = 0;
} else {
-   /*
-* periodic timers reset to APIC_TMICT when they
-* hit 0. The while loop simulates this happening N
-* times. (counter_passed %= tmcct) would also work,
-* but might be slower or not work on 32-bit??
-*/
-   while (counter_passed > tmcct)
-   counter_passed -= tmcct;
+   counter_passed %= (u64)tmcct;
tmcct -= counter_passed;
}
} else {
-- 
1.6.0.2

--
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

[ kvm-Bugs-2493498 ] Link to latest virtio drivers dead in wiki

[SourceForge.net]

Bugs item #2493498, was opened at 2009-01-08 10:34
Message generated for change (Comment added) made by kelu6
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2493498&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kenni (kelu6)
Assigned to: Nobody/Anonymous (nobody)
Summary: Link to latest virtio drivers dead in wiki

Initial Comment:
I've previously had success using the latest Virtio Windows drivers from the 
KVM Wiki instead of the latest (and older) version from Sourceforge on Windows 
Vista and 2008.

The following page in the wiki links to both the new drivers and the older 
drivers currently in Sourceforge:
http://kvm.qumranet.com/kvmwiki/VirtioWindowsDrivers

However, the link to the latest drivers has been dead for at least two weeks, 
can someone please fix it or upload the latest version to Sourceforge?

Is there any reason why the latest drivers wasn't uploaded to Sourceforge in 
the first place?

--

>Comment By: Kenni (kelu6)
Date: 2009-01-08 16:33

Message:
Ahh, thank you...isn't it quite confusing to have both an old Windows
driver as the "latest" Windows driver in SF and next to it a "driver-iso",
which apparently contains a newer version of the Windows driver??? I have
always seen the iso as a collection of all the drivers, I would never
expect the an "driver-iso" to contain newer versions of the individual
drivers.

If only the driver-iso will get updated in the future, you should really
remove the old Windows driver to avoid confusing.

--

Comment By: Dor Laor (thekozmo)
Date: 2009-01-08 11:31

Message:
The people.qumranet.com was blocked.
I updated the new location for latest pv win drivers in the wiki.
10x

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2493498&group_id=180599
--
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] qemu: report issues causing the kvm probe to fail v3

[Avi Kivity]

ehrha...@linux.vnet.ibm.com wrote:

From: Christian Ehrhardt 

The patch applies to upstream qemu as well as kvm-userspace, but since it is
the qemu configure script I think it should go to upstream qemu (Anthony)
first and with the next merge to kvm-userspace. On the other hand it is the kvm
probe so an ack from Avi in case v3 is ok would be reasonable.
  


Looks fine from here.

--
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: Win2K3 SCSI errors

[Ryan Harper]

* Anssi Kolehmainen  [2009-01-08 08:23]:
> Hi,

Hey,

Btw, thanks for all of the testing of the scsi bits in windows.  This
has been a great help in flushing out where we've got further work to
do.

> 
> Just to recap my problems with Win2K3 and SCSI...
> 
> Host: 2.6.28 x86_64 Intel Core2Duo E8500 (3.16GHz), 6gb ram
> Guest: Win2003 server, 32-bit, SP2
> KVM: 82 (both userspace and kernel modules)
> 
> qemu-system-x86_64 -name $name -smp 1 -m 1024 -vnc :$id -k fi -serial
> mon:telnet::1000$id,server,nowait -localtime -vga std -usb -usbdevice
> tablet -net nic,macaddr=00:16:3e:00:00:$id,model=e1000 -net
> tap,ifname=tap-$name -pidfile /var/run/kvm/$name.pid -boot c -drive
> index=0,media=disk,if=scsi,boot=on,file=/dev/mapper/vg0-$name
> 
> - Copying file from network drive (100mbps network) to local drive seems
>   to cause 'lsi_scsi: error: Bad Status move' 100% in one system,
>   usually somewhere after 300mb transferred.
> - Also sometimes installing Oracle DB, Bea Weblogic and/or MS SQL Server
>   seems to cause it.
> - Under normal loads it happens about once a week.
> - When running without kvm modules no errors occur.
> 
> - Writing null to local drive works just fine. Unbuffered and
>   write-trough write is about 50mb/s (whereas host can do about 95mb/s).
> - Once after such write I got 'Bad status move' error but only after
>   guest had been idling for about 30s. Resulted in Windows
>   KERNEL_INPAGE_ERROR (ntfs.sys) BSOD. Hasn't occured since.
> 
> - Not all 'Bad status moves' cause BSOD but if they do it is
>   KERNEL_INPAGE_ERROR... Feels like memory corruption to me.
> 
> - Windows event log contains few dozen of "The driver detected a
>   controller error on \Device\Scsi\sym_hu1." These come mostly in boot.
> - Another event log error 'The device did not respond within the timeout
>   period.' occurs at somewhat same time as 'Bad Status move' error.
> 
> - Bad Status move looks like it comes when scsi (write) command is
>   completed after adapter is reset. Executed SCRIPTS doesn't know
>   adapter has been reset and does bad things.
> 
> Ryan, have you been able to duplicate this? I can provide you access to
> my test system where you could try to debug this.

I've been able to duplicate the Bad Status moves on 2k8.  I've never
seen any of these issues on 2k3 R2, 32 or 64-bit.  Using 2k8 32-bit,
-smp 2, I've recreated the Bad Status moves and I have a pretty
good idea of what's wrong.  What I'm seeing is that we've queued a read
operation, proceeded to some other task, the completion function is
invoked when the io layer completes, but since we've started some other
task, lsi_command_complete gets confused (trips waiting=1 dbc!=0 , the
state of the current task) raises the phase mismatch thinking it's a
short transfer.  It then switches to the STATUS phase, but here is where
things go bad, the scripts decodes the instructions and the byte count
is wrong (!=1) and that trips the bad status BADF().

So, to fix this, first, when we complete a command and the tag we get in
the call back doesn';t match the tag we're currently executing, we have
to disconnect the current task from the scsi system.  Then, we need to
have the lsi device reselect the completed tag so we can send a proper
command complete signal to the guest.   This change requires some
reworking of the lsi_queue so we don't remove tasks from the queue until
we've signaled to the driver we've completed the task.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.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 6/7] KVM: Split IOAPIC structure

[Marcelo Tosatti]

On Thu, Jan 08, 2009 at 06:45:34PM +0800, Sheng Yang wrote:
> Prepared for reuse ioapic_redir_entry for MSI.

What is the disadvantage of dispatching the MSI interrupts to the vcpus
via the IOAPIC? Pin shortage I can think of, but adding more IOAPIC's is
possible (and wanted anyway for systems with insane amounts of net/block
devices).

That would avoid code duplication (might need to handle a few msi
specific bits).


--
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 2/7] KVM: Using gsi route for MSI device assignment

[Avi Kivity]

Sheng Yang wrote:

Convert MSI userspace interface to support gsi_msg mapping(and nobody should
be the user of the old interface...).
  


This affects device assignment only, right?

--
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 1/7] KVM: Add a route layer to convert MSI message to GSI

[Avi Kivity]

Sheng Yang wrote:

Avi's purpose, to use single kvm_set_irq() to deal with all interrupt, including
MSI. So here is it.

struct gsi_route_entry is a mapping from a special gsi(with KVM_GSI_MSG_MASK) to
MSI/MSI-X message address/data. And the struct can also be extended for other
purpose.

Now we support up to 256 gsi_route_entry mapping, and gsi is allocated by 
kernel and
provide two ioctls to userspace, which is more flexiable.

@@ -553,4 +558,25 @@ struct kvm_assigned_irq {
 #define KVM_DEV_IRQ_ASSIGN_MSI_ACTION  KVM_DEV_IRQ_ASSIGN_ENABLE_MSI
 #define KVM_DEV_IRQ_ASSIGN_ENABLE_MSI  (1 << 0)
 
+struct kvm_gsi_route_guest {

+   __u32 entries_nr;
  


Need padding here otherwise offsetof(entries) will differ on 32-bit and 
64-bit kernels.



+   struct kvm_gsi_route_entry_guest *entries;
  


Like Marcelo says, zero sized array is better here.


+};
+
+#define KVM_GSI_ROUTE_MSI  (1 << 0)
  


This looks like a flag.  Shouldn't it be a type?


+struct kvm_gsi_route_entry_guest {
  

what does _guest mean here? almost all kvm stuff is _guest related.


+   __u32 gsi;
+   __u32 type;
+   __u32 flags;
+   __u32 reserved;
+   union {
+   struct {
+   __u32 addr_lo;
+   __u32 addr_hi;
+   __u32 data;
+   } msi;
+   __u32 padding[8];
+   };
+};
+
  


Since we replace the entire table every time, how do ioapic/pic gsis work?

 
 /* The guest did something we don't support. */

@@ -336,6 +339,19 @@ void kvm_unregister_irq_mask_notifier(struct kvm *kvm, int 
irq,
  struct kvm_irq_mask_notifier *kimn);
 void kvm_fire_mask_notifiers(struct kvm *kvm, int irq, bool mask);
 
+#define KVM_GSI_ROUTE_MASK0x100ull

+struct kvm_gsi_route_entry {
+   u32 gsi;
+   u32 type;
+   u32 flags;
+   u32 reserved;
+   union {
+   struct msi_msg msi;
+   u32 reserved[8];
  


No need for reserved fields in kernel data.


+   };
+   struct hlist_node link;
+};
@@ -123,3 +123,73 @@ void kvm_fire_mask_notifiers(struct kvm *kvm, int irq, 
bool mask)
kimn->func(kimn, mask);
 }
 
+int kvm_update_gsi_route(struct kvm *kvm, struct kvm_gsi_route_entry *entry)

+{
+   struct kvm_gsi_route_entry *found_entry, *new_entry;
+   int r, gsi;
+
+   mutex_lock(&kvm->lock);
+   /* Find whether we need a update or a new entry */
+   found_entry = kvm_find_gsi_route_entry(kvm, entry->gsi);
+   if (found_entry)
+   *found_entry = *entry;
+   else {
+   gsi = find_first_zero_bit(kvm->gsi_route_bitmap,
+ KVM_NR_GSI_ROUTE_ENTRIES);
+   if (gsi >= KVM_NR_GSI_ROUTE_ENTRIES) {
+   r = -ENOSPC;
+   goto out;
+   }
+   new_entry = kzalloc(sizeof(*new_entry), GFP_KERNEL);
+   if (!new_entry) {
+   r = -ENOMEM;
+   goto out;
+   }
+   *new_entry = *entry;
+   entry->gsi = gsi | KVM_GSI_ROUTE_MASK;
+   __set_bit(gsi, kvm->gsi_route_bitmap);
+   hlist_add_head(&new_entry->link, &kvm->gsi_route_list);
+   }
+   r = 0;
+out:
+   mutex_unlock(&kvm->lock);
+   return r;
+}
  


Why not throw everything and set the new table?

I didn't see where you respond the new KVM_CAP.  It looks like a good 
place to return the maximum size of the table.


--
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 1/7] KVM: Add a route layer to convert MSI message to GSI

[Marcelo Tosatti]

On Thu, Jan 08, 2009 at 06:45:29PM +0800, Sheng Yang wrote:
>   * ioctls for VM fds
> @@ -433,6 +436,8 @@ struct kvm_trace_rec {
>  #define KVM_ASSIGN_IRQ _IOR(KVMIO, 0x70, \
>   struct kvm_assigned_irq)
>  #define KVM_REINJECT_CONTROL  _IO(KVMIO, 0x71)
> +#define KVM_REQUEST_GSI_ROUTE  _IOWR(KVMIO, 0x72, void *)
> +#define KVM_FREE_GSI_ROUTE _IOR(KVMIO, 0x73, void *)

Oh this slipped: should be struct kvm_gsi_route_guest.

>  /*
>   * ioctls for vcpu fds
> @@ -553,4 +558,25 @@ struct kvm_assigned_irq {
>  #define KVM_DEV_IRQ_ASSIGN_MSI_ACTIONKVM_DEV_IRQ_ASSIGN_ENABLE_MSI
>  #define KVM_DEV_IRQ_ASSIGN_ENABLE_MSI(1 << 0)
>  
> +struct kvm_gsi_route_guest {
> + __u32 entries_nr;
> + struct kvm_gsi_route_entry_guest *entries;
> +};

And you can use a zero sized array here.

Sorry :(
--
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

Win2K3 SCSI errors

[Anssi Kolehmainen]

Hi,

Just to recap my problems with Win2K3 and SCSI...

Host: 2.6.28 x86_64 Intel Core2Duo E8500 (3.16GHz), 6gb ram
Guest: Win2003 server, 32-bit, SP2
KVM: 82 (both userspace and kernel modules)

qemu-system-x86_64 -name $name -smp 1 -m 1024 -vnc :$id -k fi -serial
mon:telnet::1000$id,server,nowait -localtime -vga std -usb -usbdevice
tablet -net nic,macaddr=00:16:3e:00:00:$id,model=e1000 -net
tap,ifname=tap-$name -pidfile /var/run/kvm/$name.pid -boot c -drive
index=0,media=disk,if=scsi,boot=on,file=/dev/mapper/vg0-$name

- Copying file from network drive (100mbps network) to local drive seems
  to cause 'lsi_scsi: error: Bad Status move' 100% in one system,
  usually somewhere after 300mb transferred.
- Also sometimes installing Oracle DB, Bea Weblogic and/or MS SQL Server
  seems to cause it.
- Under normal loads it happens about once a week.
- When running without kvm modules no errors occur.

- Writing null to local drive works just fine. Unbuffered and
  write-trough write is about 50mb/s (whereas host can do about 95mb/s).
- Once after such write I got 'Bad status move' error but only after
  guest had been idling for about 30s. Resulted in Windows
  KERNEL_INPAGE_ERROR (ntfs.sys) BSOD. Hasn't occured since.

- Not all 'Bad status moves' cause BSOD but if they do it is
  KERNEL_INPAGE_ERROR... Feels like memory corruption to me.

- Windows event log contains few dozen of "The driver detected a
  controller error on \Device\Scsi\sym_hu1." These come mostly in boot.
- Another event log error 'The device did not respond within the timeout
  period.' occurs at somewhat same time as 'Bad Status move' error.

- Bad Status move looks like it comes when scsi (write) command is
  completed after adapter is reset. Executed SCRIPTS doesn't know
  adapter has been reset and does bad things.

Ryan, have you been able to duplicate this? I can provide you access to
my test system where you could try to debug this.

-- 
Anssi Kolehmainen
anssi.kolehmai...@iki.fi
040-5085390
--
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] ia64 - expose registers in struct kvm_regs

[Jes Sorensen]

Zhang, Xiantao wrote:
Avi can pickup it into kvm.git, and seems it is unnecessary to push into 2.6.29, right ? 
Xiantao


Yes, it's not urgent, if we get it in within a reasonable amount of
time, thats ok.

Thanks Avi!

Cheers,
Jes



Jes Sorensen wrote:

Hi,

I think this one got lost in the battle. Would you mind sticking it in
or do you want me to send it to Tony?

Cheers,
Jes


--
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] kvm: qemu: virtio-net: migration fixes

[Avi Kivity]

Mark McLoughlin wrote:

Hi Avi,

A new version, with Anthony's suggested savevm version number bump.
  


Applied, thanks.  There wasn't much chance of me applying this before 
Anthony; so next time please send an incremental patch.


--
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] ia64 - expose registers in struct kvm_regs

[Avi Kivity]

Jes Sorensen wrote:

Hi,

I think this one got lost in the battle. Would you mind sticking it in
or do you want me to send it to Tony?


Applied, thanks.  It's a kvm file so kvm.git is the right path.

--
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: BUG() with SCSI-interfaced disk images

[Ryan Harper]

* John Morrissey  [2009-01-07 20:16]:
> On Wed, Jan 07, 2009 at 04:34:50PM -0600, Ryan Harper wrote:
> > * John Morrissey  [2009-01-07 15:59]:
> > > On Fri, Dec 26, 2008 at 04:00:28PM -0500, John Morrissey wrote:
> > > > I'm encountering a kernel BUG() in guests using SCSI-interfaced disk
> > > > images. I've tried with the Debian packaging of KVM 79 and 82; both
> > > > exhibit the same behavior (disclaimer: Debian has about a dozen
> > > > patches in their kvm packaging, but they all seem to be changes to the
> > > > build/install process or security-related).
> > > 
> > > Not to be pushy, but does anyone have any ideas on this, or can I
> > > provide any additional information? I'm afraid I'm a bit over my head
> > > when debugging kernel internals.
> > 
> > Sorry, I meant to respond.  This is more than likely a SCSI emulation
> > error rather than a kernel error.  I've seen the error a couple of
> > times, but I don't have a fix for the issue yet as I don't have a
> > reliable way to reproduce the error.  If you have an easy way to
> > reproduce the bug, I'll see if I can figure out a fix.  
> 
> I can reproduce this reliably when fscking a filesystem in a .vmdk I have.
> I can't give you the vmdk or a dump of the filesystem, but I can devote some
> time to troubleshoot this if you can guide me a little. If having the vmdk
> is really important, I might be able to sanitize it enough to send it to you
> (hopefully not making this bug unreproducible in the process).

I don't need the vmdk, but if there is some other repeatable process
that can trigger this for you, getting that will allow me to recreate
the issue myself.  For example, installing Debian into a vmdk, reboot,
and then fsck'ing from inside the vm would trigger it.  Finding some
sort of repeatable process that can trip the bug but without using any
of your specific data would be the best way to move forward with the
bug.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.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

[PATCH] qemu: report issues causing the kvm probe to fail v3

[ehrhardt]

From: Christian Ehrhardt 

The patch applies to upstream qemu as well as kvm-userspace, but since it is
the qemu configure script I think it should go to upstream qemu (Anthony)
first and with the next merge to kvm-userspace. On the other hand it is the kvm
probe so an ack from Avi in case v3 is ok would be reasonable.

*updates*
v2 - it also reports other errors than just #error preprocessor statements
 (requested by Avi)
v3 - In case awk or grep is not installed it now gracfully (silently)
 fails still disabling kvm (requested by Anthony)

This patch is about reporting more details of the issue if configuring kvm
fails. Therefore this patch keeps the qemu style configure output which is a
list of "$Feature $Status", but extend the "no" result like "KVM Support no"
with some more information.

There might be a lot of things going wrong with that probe and I don't want
to handle all of them, but if it is one of the known checks e.g. for
KVM_API_VERSION then we could grep/awk that out and report it. The patch
reports in case of a known case in the style
"KVM support no - (Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS)"

In case more than one #error is triggered it creates a comma separated list in
those brackets and in case it is something else than an #error it just reports
plain old "no".

Signed-off-by: Christian Ehrhardt 
---

 configure |   27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/qemu/configure b/qemu/configure
--- a/qemu/configure
+++ b/qemu/configure
@@ -1002,13 +1002,17 @@ if test "$kvm" = "yes" ; then
 if test "$kvm" = "yes" ; then
 cat > $TMPC <
-#if !defined(KVM_API_VERSION) || \
-KVM_API_VERSION < 12 || \
-KVM_API_VERSION > 12 || \
-!defined(KVM_CAP_USER_MEMORY) || \
-!defined(KVM_CAP_SET_TSS_ADDR) || \
-!defined(KVM_CAP_DESTROY_MEMORY_REGION_WORKS)
+#if !defined(KVM_API_VERSION) || KVM_API_VERSION < 12 || KVM_API_VERSION > 12
 #error Invalid KVM version
+#endif
+#if !defined(KVM_CAP_USER_MEMORY)
+#error Missing KVM capability KVM_CAP_USER_MEMORY
+#endif
+#if !defined(KVM_CAP_SET_TSS_ADDR)
+#error Missing KVM capability KVM_CAP_SET_TSS_ADDR
+#endif
+#if !defined(KVM_CAP_DESTROY_MEMORY_REGION_WORKS)
+#error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS
 #endif
 int main(void) { return 0; }
 EOF
@@ -1021,7 +1025,16 @@ EOF
   > /dev/null 2>/dev/null ; then
 :
   else
-kvm="no"
+kvm="no";
+if [ -x "`which awk 2>/dev/null`" ] && \
+   [ -x "`which grep 2>/dev/null`" ]; then
+  kvmerr=`$cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $kvm_cflags $TMPC 2>&1 \
+   | grep "error: " \
+   | awk -F "error: " '{if (NR>1) printf(", "); printf("%s",$2);}'`
+  if test "$kvmerr" != "" ; then
+kvm="no - (${kvmerr})"
+  fi
+fi
   fi
 fi
 
--
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: KVM: Merge MSI handling to kvm_set_irq

[Mike Day]

On 07/01/09 18:42 +0800, Sheng Yang wrote:
> Using kvm_set_irq to handle all interrupt injection.
> 
> Signed-off-by: Sheng Yang 
> ---

> +static void gsi_dispatch(struct kvm *kvm, u32 gsi)

...

> + case IOAPIC_FIXED:
> + for (vcpu_id = 0; deliver_bitmask != 0; vcpu_id++) {
> + if (!(deliver_bitmask & (1 << vcpu_id)))
> + continue;
> + deliver_bitmask &= ~(1 << vcpu_id);
> + vcpu = ioapic->kvm->vcpus[vcpu_id];
> + if (vcpu)
> + kvm_apic_set_irq(vcpu, vector,
> + trig_mode);
> + }
> + break;
> + default:
> + break;
> + }

In cases such as the for() loop above, which are numerous in the
patchset, I wonder if using bitops would be slightly better:

case IOAPIC_FIXED:
while (deliver_bitmask != 0) {
vcpu_id = ffs(deliver_bitmask);
__clear_bit(vcpu_id - 1, &deliver_bitmask);
vcpu = ioapic->kvm->vcpus[vcpu_id - 1];
if (vcpu)
kvm_apic_set_irq(vcpu, vector,
 trig_mode);
} ;


I did a quick check and the second example compiles to a more
consise set of assembler instructions. The current code uses bitops in
cases like this.

Mike

-- 
Mike Day
http://www.ncultra.org
AIM: ncmikeday |  Yahoo IM: ultra.runner
PGP key: http://www.ncultra.org/ncmike/pubkey.asc
--
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] ia64 - expose registers in struct kvm_regs

[Zhang, Xiantao]

Avi can pickup it into kvm.git, and seems it is unnecessary to push into 
2.6.29, right ? 
Xiantao

Jes Sorensen wrote:
> Hi,
> 
> I think this one got lost in the battle. Would you mind sticking it in
> or do you want me to send it to Tony?
> 
> Cheers,
> Jes

--
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

[patch] ia64 - expose registers in struct kvm_regs

[Jes Sorensen]

Hi,

I think this one got lost in the battle. Would you mind sticking it in
or do you want me to send it to Tony?

Cheers,
Jes
Provided register layout for struct kvm_regs exposed to userland.

Signed-off-by: Jes Sorensen 

---
 arch/ia64/include/asm/kvm.h |   35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

Index: linux-2.6.git/arch/ia64/include/asm/kvm.h
===
--- linux-2.6.git.orig/arch/ia64/include/asm/kvm.h
+++ linux-2.6.git/arch/ia64/include/asm/kvm.h
@@ -162,7 +162,40 @@
unsigned long  vcpuid[5];
unsigned long  vpsr;
unsigned long  vpr;
-   unsigned long  vcr[128];
+   union {
+   unsigned long  vcr[128];
+   struct {
+   unsigned long dcr;
+   unsigned long itm;
+   unsigned long iva;
+   unsigned long rsv1[5];
+   unsigned long pta;
+   unsigned long rsv2[7];
+   unsigned long ipsr;
+   unsigned long isr;
+   unsigned long rsv3;
+   unsigned long iip;
+   unsigned long ifa;
+   unsigned long itir;
+   unsigned long iipa;
+   unsigned long ifs;
+   unsigned long iim;
+   unsigned long iha;
+   unsigned long rsv4[38];
+   unsigned long lid;
+   unsigned long ivr;
+   unsigned long tpr;
+   unsigned long eoi;
+   unsigned long irr[4];
+   unsigned long itv;
+   unsigned long pmv;
+   unsigned long cmcv;
+   unsigned long rsv5[5];
+   unsigned long lrr0;
+   unsigned long lrr1;
+   unsigned long rsv6[46];
+   };
+   };
 };
 
 struct kvm_regs {

[PATCH] KVM-userspace: allow CPUID vendor override

[Andre Przywara]

Hi,

currently KVM always propagates the host CPU vendor ID to the guest. This
patch allows to override this behavior by explicitly specifying a vendor ID
with -cpu qemu64,vendor=KVMKVMKVMKVM. This proved to be useful for cross
vendor migration tests.

Regards,
Andre.

Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Jochen Polster; Thomas M. McCoy; Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632


Signed-off-by: Andre Przywara 
---
 qemu/target-i386/cpu.h|1 +
 qemu/target-i386/helper.c |5 -
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/qemu/target-i386/cpu.h b/qemu/target-i386/cpu.h
index 944e386..d83d62b 100644
--- a/qemu/target-i386/cpu.h
+++ b/qemu/target-i386/cpu.h
@@ -628,6 +628,7 @@ typedef struct CPUX86State {
 uint32_t cpuid_ext2_features;
 uint32_t cpuid_ext3_features;
 uint32_t cpuid_apic_id;
+uint32_t cpuid_vendor_override;
 
 #ifdef USE_KQEMU
 int kqemu_enabled;
diff --git a/qemu/target-i386/helper.c b/qemu/target-i386/helper.c
index cda0390..7dbe36b 100644
--- a/qemu/target-i386/helper.c
+++ b/qemu/target-i386/helper.c
@@ -103,6 +103,7 @@ typedef struct x86_def_t {
 uint32_t features, ext_features, ext2_features, ext3_features;
 uint32_t xlevel;
 char model_id[48];
+int vendor_override;
 } x86_def_t;
 
 #define I486_FEATURES (CPUID_FP87 | CPUID_VME | CPUID_PSE)
@@ -335,6 +336,7 @@ static int cpu_x86_find_by_name(x86_def_t *x86_cpu_def, 
const char *cpu_model)
 x86_cpu_def->vendor2 |= ((uint8_t)val[i + 4]) << (8 * i);
 x86_cpu_def->vendor3 |= ((uint8_t)val[i + 8]) << (8 * i);
 }
+x86_cpu_def->vendor_override = 1;
 } else if (!strcmp(featurestr, "model_id")) {
 pstrcpy(x86_cpu_def->model_id, sizeof(x86_cpu_def->model_id),
 val);
@@ -387,6 +389,7 @@ static int cpu_x86_register (CPUX86State *env, const char 
*cpu_model)
 env->cpuid_vendor2 = CPUID_VENDOR_INTEL_2;
 env->cpuid_vendor3 = CPUID_VENDOR_INTEL_3;
 }
+env->cpuid_vendor_override = def->vendor_override;
 env->cpuid_level = def->level;
 if (def->family > 0x0f)
 env->cpuid_version = 0xf00 | ((def->family - 0x0f) << 20);
@@ -1435,7 +1438,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
  * isn't supported in compatibility mode on Intel.  so advertise the
  * actuall cpu, and say goodbye to migration between different vendors
  * is you use compatibility mode. */
-if (kvm_enabled())
+if (kvm_enabled() && ! env->cpuid_vendor_override)
 host_cpuid(0, NULL, ebx, ecx, edx);
 break;
 case 1:
-- 
1.5.2.2


--
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] kvm: userspace: change vtd.o to iommu.o in Kbuild

[Amit Shah]

On Thu, Jan 08, 2009 at 03:27:12PM +0800, Huang, Wei W wrote:
> vtd.c has been renamed to iommu.c, need to change it in Kbuild accordingly.
> 
> Signed-off-by: Wei Huang 
> ---
>  kernel/x86/Kbuild |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/x86/Kbuild b/kernel/x86/Kbuild
> index c4723b1..48339b4 100644
> --- a/kernel/x86/Kbuild
> +++ b/kernel/x86/Kbuild
> @@ -10,7 +10,7 @@ ifeq ($(EXT_CONFIG_KVM_TRACE),y)
>  kvm-objs += kvm_trace.o
>  endif
>  ifeq ($(CONFIG_DMAR),y)
> -kvm-objs += vtd.o
> +kvm-objs += iommu.o

This won't be able to build an older kernel.

Amit
--
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

[PATCH 5/7] KVM: Merge MSI handling to kvm_set_irq

[Sheng Yang]

Using kvm_set_irq to handle all interrupt injection.

Signed-off-by: Sheng Yang 
---
 include/linux/kvm_host.h |2 +-
 virt/kvm/irq_comm.c  |   79 +++--
 virt/kvm/kvm_main.c  |   79 +++---
 3 files changed, 81 insertions(+), 79 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index eab9588..bfdaab9 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -351,7 +351,7 @@ struct kvm_gsi_route_entry {
struct hlist_node link;
 };
 
-void kvm_set_irq(struct kvm *kvm, int irq_source_id, int irq, int level);
+void kvm_set_irq(struct kvm *kvm, int irq_source_id, u32 gsi, int level);
 void kvm_notify_acked_irq(struct kvm *kvm, unsigned gsi);
 void kvm_register_irq_ack_notifier(struct kvm *kvm,
   struct kvm_irq_ack_notifier *kian);
diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
index f8b22a1..e6ce472 100644
--- a/virt/kvm/irq_comm.c
+++ b/virt/kvm/irq_comm.c
@@ -24,10 +24,81 @@
 
 #include "ioapic.h"
 
+#ifdef CONFIG_X86
+#include 
+#endif
+
+static void gsi_dispatch(struct kvm *kvm, u32 gsi)
+{
+   int vcpu_id;
+   struct kvm_vcpu *vcpu;
+   struct kvm_ioapic *ioapic = ioapic_irqchip(kvm);
+   struct kvm_gsi_route_entry *gsi_entry;
+   int dest_id, vector, dest_mode, trig_mode, delivery_mode;
+   u32 deliver_bitmask;
+
+   BUG_ON(!ioapic);
+
+   gsi_entry = kvm_find_gsi_route_entry(kvm, gsi);
+   if (!gsi_entry) {
+   printk(KERN_WARNING "kvm: fail to find correlated gsi entry\n");
+   return;
+   }
+
+#ifdef CONFIG_X86
+   if (gsi_entry->type & KVM_GSI_ROUTE_MSI) {
+   dest_id = (gsi_entry->msi.address_lo & MSI_ADDR_DEST_ID_MASK)
+   >> MSI_ADDR_DEST_ID_SHIFT;
+   vector = (gsi_entry->msi.data & MSI_DATA_VECTOR_MASK)
+   >> MSI_DATA_VECTOR_SHIFT;
+   dest_mode = test_bit(MSI_ADDR_DEST_MODE_SHIFT,
+   (unsigned long *)&gsi_entry->msi.address_lo);
+   trig_mode = test_bit(MSI_DATA_TRIGGER_SHIFT,
+   (unsigned long *)&gsi_entry->msi.data);
+   delivery_mode = test_bit(MSI_DATA_DELIVERY_MODE_SHIFT,
+   (unsigned long *)&gsi_entry->msi.data);
+   deliver_bitmask = kvm_ioapic_get_delivery_bitmask(ioapic,
+   dest_id, dest_mode);
+   /* IOAPIC delivery mode value is the same as MSI here */
+   switch (delivery_mode) {
+   case IOAPIC_LOWEST_PRIORITY:
+   vcpu = kvm_get_lowest_prio_vcpu(ioapic->kvm, vector,
+   deliver_bitmask);
+   if (vcpu != NULL)
+   kvm_apic_set_irq(vcpu, vector, trig_mode);
+   else
+   printk(KERN_INFO
+  "kvm: null lowest priority vcpu!\n");
+   break;
+   case IOAPIC_FIXED:
+   for (vcpu_id = 0; deliver_bitmask != 0; vcpu_id++) {
+   if (!(deliver_bitmask & (1 << vcpu_id)))
+   continue;
+   deliver_bitmask &= ~(1 << vcpu_id);
+   vcpu = ioapic->kvm->vcpus[vcpu_id];
+   if (vcpu)
+   kvm_apic_set_irq(vcpu, vector,
+   trig_mode);
+   }
+   break;
+   default:
+   break;
+   }
+   }
+#endif /* CONFIG_X86 */
+}
+
 /* This should be called with the kvm->lock mutex held */
-void kvm_set_irq(struct kvm *kvm, int irq_source_id, int irq, int level)
+void kvm_set_irq(struct kvm *kvm, int irq_source_id, u32 gsi, int level)
 {
-   unsigned long *irq_state = (unsigned long *)&kvm->arch.irq_states[irq];
+   unsigned long *irq_state;
+
+   if (gsi & KVM_GSI_ROUTE_MASK) {
+   gsi_dispatch(kvm, gsi);
+   return;
+   }
+
+   irq_state = (unsigned long *)&kvm->arch.irq_states[gsi];
 
/* Logical OR for level trig interrupt */
if (level)
@@ -39,9 +110,9 @@ void kvm_set_irq(struct kvm *kvm, int irq_source_id, int 
irq, int level)
 * IOAPIC.  So set the bit in both. The guest will ignore
 * writes to the unused one.
 */
-   kvm_ioapic_set_irq(ioapic_irqchip(kvm), irq, !!(*irq_state));
+   kvm_ioapic_set_irq(ioapic_irqchip(kvm), gsi, !!(*irq_state));
 #ifdef CONFIG_X86
-   kvm_pic_set_irq(pic_irqchip(kvm), irq, !!(*irq_state));
+   kvm_pic_set_irq(pic_irqchip(kvm), gsi, !!(*irq_state));
 #endif
 }
 
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index fb2

[PATCH 7/7] KVM: Unified the delivery of IOAPIC and MSI

[Sheng Yang]

Signed-off-by: Sheng Yang 
---
 include/linux/kvm_host.h |3 ++
 virt/kvm/ioapic.c|   84 
 virt/kvm/irq_comm.c  |   86 --
 3 files changed, 86 insertions(+), 87 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index bfdaab9..2736dbf 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -351,6 +351,9 @@ struct kvm_gsi_route_entry {
struct hlist_node link;
 };
 
+void kvm_get_intr_delivery_bitmask(struct kvm_ioapic *ioapic,
+  union kvm_ioapic_redirect_entry *entry,
+  u32 *deliver_bitmask);
 void kvm_set_irq(struct kvm *kvm, int irq_source_id, u32 gsi, int level);
 void kvm_notify_acked_irq(struct kvm *kvm, unsigned gsi);
 void kvm_register_irq_ack_notifier(struct kvm *kvm,
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index b6530e9..951df12 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -200,75 +200,53 @@ u32 kvm_ioapic_get_delivery_bitmask(struct kvm_ioapic 
*ioapic, u8 dest,
 
 static int ioapic_deliver(struct kvm_ioapic *ioapic, int irq)
 {
-   u8 dest = ioapic->redirtbl[irq].fields.dest_id;
-   u8 dest_mode = ioapic->redirtbl[irq].fields.dest_mode;
-   u8 delivery_mode = ioapic->redirtbl[irq].fields.delivery_mode;
-   u8 vector = ioapic->redirtbl[irq].fields.vector;
-   u8 trig_mode = ioapic->redirtbl[irq].fields.trig_mode;
+   union kvm_ioapic_redirect_entry entry = ioapic->redirtbl[irq];
u32 deliver_bitmask;
struct kvm_vcpu *vcpu;
int vcpu_id, r = 0;
 
ioapic_debug("dest=%x dest_mode=%x delivery_mode=%x "
 "vector=%x trig_mode=%x\n",
-dest, dest_mode, delivery_mode, vector, trig_mode);
+entry.fields.dest, entry.fields.dest_mode,
+entry.fields.delivery_mode, entry.fields.vector,
+entry.fields.trig_mode);
 
-   deliver_bitmask = kvm_ioapic_get_delivery_bitmask(ioapic, dest,
- dest_mode);
+   kvm_get_intr_delivery_bitmask(ioapic, &entry, &deliver_bitmask);
if (!deliver_bitmask) {
ioapic_debug("no target on destination\n");
return 0;
}
 
-   switch (delivery_mode) {
-   case IOAPIC_LOWEST_PRIORITY:
-   vcpu = kvm_get_lowest_prio_vcpu(ioapic->kvm, vector,
-   deliver_bitmask);
+   /* Always delivery PIT interrupt to vcpu 0 */
 #ifdef CONFIG_X86
-   if (irq == 0)
-   vcpu = ioapic->kvm->vcpus[0];
+   if (irq == 0)
+   deliver_bitmask = 1 << 0;
 #endif
-   if (vcpu != NULL)
-   r = ioapic_inj_irq(ioapic, vcpu, vector,
-  trig_mode, delivery_mode);
-   else
-   ioapic_debug("null lowest prio vcpu: "
-"mask=%x vector=%x delivery_mode=%x\n",
-deliver_bitmask, vector, 
IOAPIC_LOWEST_PRIORITY);
-   break;
-   case IOAPIC_FIXED:
-#ifdef CONFIG_X86
-   if (irq == 0)
-   deliver_bitmask = 1;
-#endif
-   for (vcpu_id = 0; deliver_bitmask != 0; vcpu_id++) {
-   if (!(deliver_bitmask & (1 << vcpu_id)))
-   continue;
-   deliver_bitmask &= ~(1 << vcpu_id);
-   vcpu = ioapic->kvm->vcpus[vcpu_id];
-   if (vcpu) {
-   r = ioapic_inj_irq(ioapic, vcpu, vector,
-  trig_mode, delivery_mode);
-   }
-   }
-   break;
-   case IOAPIC_NMI:
-   for (vcpu_id = 0; deliver_bitmask != 0; vcpu_id++) {
-   if (!(deliver_bitmask & (1 << vcpu_id)))
-   continue;
-   deliver_bitmask &= ~(1 << vcpu_id);
-   vcpu = ioapic->kvm->vcpus[vcpu_id];
-   if (vcpu)
+
+   for (vcpu_id = 0; deliver_bitmask != 0; vcpu_id++) {
+   if (!(deliver_bitmask & (1 << vcpu_id)))
+   continue;
+   deliver_bitmask &= ~(1 << vcpu_id);
+   vcpu = ioapic->kvm->vcpus[vcpu_id];
+   if (vcpu) {
+   if (entry.fields.delivery_mode ==
+   IOAPIC_LOWEST_PRIORITY ||
+   entry.fields.delivery_mode == IOAPIC_FIXED)
+   r = ioapic_inj_irq(ioapic, vcpu,
+  entry.fields.vector,
+  entry.fields.trig_mode,
+   

[PATCH 1/7] KVM: Add a route layer to convert MSI message to GSI

[Sheng Yang]

Avi's purpose, to use single kvm_set_irq() to deal with all interrupt, including
MSI. So here is it.

struct gsi_route_entry is a mapping from a special gsi(with KVM_GSI_MSG_MASK) to
MSI/MSI-X message address/data. And the struct can also be extended for other
purpose.

Now we support up to 256 gsi_route_entry mapping, and gsi is allocated by 
kernel and
provide two ioctls to userspace, which is more flexiable.

Signed-off-by: Sheng Yang 
---
 include/linux/kvm.h  |   26 +++
 include/linux/kvm_host.h |   20 +
 virt/kvm/irq_comm.c  |   70 ++
 virt/kvm/kvm_main.c  |  105 ++
 4 files changed, 221 insertions(+), 0 deletions(-)

diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 71c150f..bbefce6 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -399,6 +399,9 @@ struct kvm_trace_rec {
 #if defined(CONFIG_X86)
 #define KVM_CAP_REINJECT_CONTROL 24
 #endif
+#if defined(CONFIG_X86)
+#define KVM_CAP_GSI_ROUTE 25
+#endif
 
 /*
  * ioctls for VM fds
@@ -433,6 +436,8 @@ struct kvm_trace_rec {
 #define KVM_ASSIGN_IRQ _IOR(KVMIO, 0x70, \
struct kvm_assigned_irq)
 #define KVM_REINJECT_CONTROL  _IO(KVMIO, 0x71)
+#define KVM_REQUEST_GSI_ROUTE_IOWR(KVMIO, 0x72, void *)
+#define KVM_FREE_GSI_ROUTE   _IOR(KVMIO, 0x73, void *)
 
 /*
  * ioctls for vcpu fds
@@ -553,4 +558,25 @@ struct kvm_assigned_irq {
 #define KVM_DEV_IRQ_ASSIGN_MSI_ACTION  KVM_DEV_IRQ_ASSIGN_ENABLE_MSI
 #define KVM_DEV_IRQ_ASSIGN_ENABLE_MSI  (1 << 0)
 
+struct kvm_gsi_route_guest {
+   __u32 entries_nr;
+   struct kvm_gsi_route_entry_guest *entries;
+};
+
+#define KVM_GSI_ROUTE_MSI  (1 << 0)
+struct kvm_gsi_route_entry_guest {
+   __u32 gsi;
+   __u32 type;
+   __u32 flags;
+   __u32 reserved;
+   union {
+   struct {
+   __u32 addr_lo;
+   __u32 addr_hi;
+   __u32 data;
+   } msi;
+   __u32 padding[8];
+   };
+};
+
 #endif
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index a8bcad0..6a00201 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -136,6 +136,9 @@ struct kvm {
unsigned long mmu_notifier_seq;
long mmu_notifier_count;
 #endif
+   struct hlist_head gsi_route_list;
+#define KVM_NR_GSI_ROUTE_ENTRIES256
+   DECLARE_BITMAP(gsi_route_bitmap, KVM_NR_GSI_ROUTE_ENTRIES);
 };
 
 /* The guest did something we don't support. */
@@ -336,6 +339,19 @@ void kvm_unregister_irq_mask_notifier(struct kvm *kvm, int 
irq,
  struct kvm_irq_mask_notifier *kimn);
 void kvm_fire_mask_notifiers(struct kvm *kvm, int irq, bool mask);
 
+#define KVM_GSI_ROUTE_MASK0x100ull
+struct kvm_gsi_route_entry {
+   u32 gsi;
+   u32 type;
+   u32 flags;
+   u32 reserved;
+   union {
+   struct msi_msg msi;
+   u32 reserved[8];
+   };
+   struct hlist_node link;
+};
+
 void kvm_set_irq(struct kvm *kvm, int irq_source_id, int irq, int level);
 void kvm_notify_acked_irq(struct kvm *kvm, unsigned gsi);
 void kvm_register_irq_ack_notifier(struct kvm *kvm,
@@ -343,6 +359,10 @@ void kvm_register_irq_ack_notifier(struct kvm *kvm,
 void kvm_unregister_irq_ack_notifier(struct kvm_irq_ack_notifier *kian);
 int kvm_request_irq_source_id(struct kvm *kvm);
 void kvm_free_irq_source_id(struct kvm *kvm, int irq_source_id);
+int kvm_update_gsi_route(struct kvm *kvm, struct kvm_gsi_route_entry *entry);
+struct kvm_gsi_route_entry *kvm_find_gsi_route_entry(struct kvm *kvm, u32 gsi);
+void kvm_free_gsi_route(struct kvm *kvm, struct kvm_gsi_route_entry *entry);
+void kvm_free_gsi_route_list(struct kvm *kvm);
 
 #ifdef CONFIG_DMAR
 int kvm_iommu_map_pages(struct kvm *kvm, gfn_t base_gfn,
diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
index 5162a41..64ca4cf 100644
--- a/virt/kvm/irq_comm.c
+++ b/virt/kvm/irq_comm.c
@@ -123,3 +123,73 @@ void kvm_fire_mask_notifiers(struct kvm *kvm, int irq, 
bool mask)
kimn->func(kimn, mask);
 }
 
+int kvm_update_gsi_route(struct kvm *kvm, struct kvm_gsi_route_entry *entry)
+{
+   struct kvm_gsi_route_entry *found_entry, *new_entry;
+   int r, gsi;
+
+   mutex_lock(&kvm->lock);
+   /* Find whether we need a update or a new entry */
+   found_entry = kvm_find_gsi_route_entry(kvm, entry->gsi);
+   if (found_entry)
+   *found_entry = *entry;
+   else {
+   gsi = find_first_zero_bit(kvm->gsi_route_bitmap,
+ KVM_NR_GSI_ROUTE_ENTRIES);
+   if (gsi >= KVM_NR_GSI_ROUTE_ENTRIES) {
+   r = -ENOSPC;
+   goto out;
+   }
+   new_entry = kzalloc(sizeof(*new_entry), GFP_KERNEL);
+   if (!new_entry) {
+   r = -ENOMEM;
+ 

[PATCH 4/7] KVM: Using ioapic_irqchip() macro for kvm_set_irq

[Sheng Yang]

Signed-off-by: Sheng Yang 
---
 virt/kvm/irq_comm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
index 64ca4cf..f8b22a1 100644
--- a/virt/kvm/irq_comm.c
+++ b/virt/kvm/irq_comm.c
@@ -39,7 +39,7 @@ void kvm_set_irq(struct kvm *kvm, int irq_source_id, int irq, 
int level)
 * IOAPIC.  So set the bit in both. The guest will ignore
 * writes to the unused one.
 */
-   kvm_ioapic_set_irq(kvm->arch.vioapic, irq, !!(*irq_state));
+   kvm_ioapic_set_irq(ioapic_irqchip(kvm), irq, !!(*irq_state));
 #ifdef CONFIG_X86
kvm_pic_set_irq(pic_irqchip(kvm), irq, !!(*irq_state));
 #endif
-- 
1.5.4.5

--
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

[PATCH 2/7] KVM: Using gsi route for MSI device assignment

[Sheng Yang]

Convert MSI userspace interface to support gsi_msg mapping(and nobody should
be the user of the old interface...).

Signed-off-by: Sheng Yang 
---
 include/linux/kvm_host.h |1 -
 virt/kvm/kvm_main.c  |   79 ++
 2 files changed, 45 insertions(+), 35 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 6a00201..eab9588 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -316,7 +316,6 @@ struct kvm_assigned_dev_kernel {
int host_irq;
bool host_irq_disabled;
int guest_irq;
-   struct msi_msg guest_msi;
 #define KVM_ASSIGNED_DEV_GUEST_INTX(1 << 0)
 #define KVM_ASSIGNED_DEV_GUEST_MSI (1 << 1)
 #define KVM_ASSIGNED_DEV_HOST_INTX (1 << 8)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 8aa939c..3bbb59f 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -92,44 +92,56 @@ static void assigned_device_msi_dispatch(struct 
kvm_assigned_dev_kernel *dev)
int vcpu_id;
struct kvm_vcpu *vcpu;
struct kvm_ioapic *ioapic = ioapic_irqchip(dev->kvm);
-   int dest_id = (dev->guest_msi.address_lo & MSI_ADDR_DEST_ID_MASK)
-   >> MSI_ADDR_DEST_ID_SHIFT;
-   int vector = (dev->guest_msi.data & MSI_DATA_VECTOR_MASK)
-   >> MSI_DATA_VECTOR_SHIFT;
-   int dest_mode = test_bit(MSI_ADDR_DEST_MODE_SHIFT,
-   (unsigned long *)&dev->guest_msi.address_lo);
-   int trig_mode = test_bit(MSI_DATA_TRIGGER_SHIFT,
-   (unsigned long *)&dev->guest_msi.data);
-   int delivery_mode = test_bit(MSI_DATA_DELIVERY_MODE_SHIFT,
-   (unsigned long *)&dev->guest_msi.data);
+   struct kvm_gsi_route_entry *gsi_entry;
+   int dest_id, vector, dest_mode, trig_mode, delivery_mode;
u32 deliver_bitmask;
 
BUG_ON(!ioapic);
 
-   deliver_bitmask = kvm_ioapic_get_delivery_bitmask(ioapic,
+   gsi_entry = kvm_find_gsi_route_entry(dev->kvm, dev->guest_irq);
+   if (!gsi_entry) {
+   printk(KERN_WARNING "kvm: fail to find correlated gsi entry\n");
+   return;
+   }
+
+   if (gsi_entry->type & KVM_GSI_ROUTE_MSI) {
+   dest_id = (gsi_entry->msi.address_lo & MSI_ADDR_DEST_ID_MASK)
+   >> MSI_ADDR_DEST_ID_SHIFT;
+   vector = (gsi_entry->msi.data & MSI_DATA_VECTOR_MASK)
+   >> MSI_DATA_VECTOR_SHIFT;
+   dest_mode = test_bit(MSI_ADDR_DEST_MODE_SHIFT,
+   (unsigned long *)&gsi_entry->msi.address_lo);
+   trig_mode = test_bit(MSI_DATA_TRIGGER_SHIFT,
+   (unsigned long *)&gsi_entry->msi.data);
+   delivery_mode = test_bit(MSI_DATA_DELIVERY_MODE_SHIFT,
+   (unsigned long *)&gsi_entry->msi.data);
+   deliver_bitmask = kvm_ioapic_get_delivery_bitmask(ioapic,
dest_id, dest_mode);
-   /* IOAPIC delivery mode value is the same as MSI here */
-   switch (delivery_mode) {
-   case IOAPIC_LOWEST_PRIORITY:
-   vcpu = kvm_get_lowest_prio_vcpu(ioapic->kvm, vector,
-   deliver_bitmask);
-   if (vcpu != NULL)
-   kvm_apic_set_irq(vcpu, vector, trig_mode);
-   else
-   printk(KERN_INFO "kvm: null lowest priority vcpu!\n");
-   break;
-   case IOAPIC_FIXED:
-   for (vcpu_id = 0; deliver_bitmask != 0; vcpu_id++) {
-   if (!(deliver_bitmask & (1 << vcpu_id)))
-   continue;
-   deliver_bitmask &= ~(1 << vcpu_id);
-   vcpu = ioapic->kvm->vcpus[vcpu_id];
-   if (vcpu)
+   /* IOAPIC delivery mode value is the same as MSI here */
+   switch (delivery_mode) {
+   case IOAPIC_LOWEST_PRIORITY:
+   vcpu = kvm_get_lowest_prio_vcpu(ioapic->kvm, vector,
+   deliver_bitmask);
+   if (vcpu != NULL)
kvm_apic_set_irq(vcpu, vector, trig_mode);
+   else
+   printk(KERN_INFO
+  "kvm: null lowest priority vcpu!\n");
+   break;
+   case IOAPIC_FIXED:
+   for (vcpu_id = 0; deliver_bitmask != 0; vcpu_id++) {
+   if (!(deliver_bitmask & (1 << vcpu_id)))
+   continue;
+   deliver_bitmask &= ~(1 << vcpu_id);
+   vcpu = ioapic->kvm->vcpus[vcpu_id];
+   if (vcpu)
+   kvm_apic_set_irq(vcpu, vector,
+   

[PATCH 6/7] KVM: Split IOAPIC structure

[Sheng Yang]

Prepared for reuse ioapic_redir_entry for MSI.

Signed-off-by: Sheng Yang 
---
 include/linux/kvm_types.h |   17 +
 virt/kvm/ioapic.c |6 +++---
 virt/kvm/ioapic.h |   17 +
 3 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/include/linux/kvm_types.h b/include/linux/kvm_types.h
index 5f4a18c..46e3d8d 100644
--- a/include/linux/kvm_types.h
+++ b/include/linux/kvm_types.h
@@ -52,4 +52,21 @@ struct kvm_pio_request {
int rep;
 };
 
+union kvm_ioapic_redirect_entry {
+   u64 bits;
+   struct {
+   u8 vector;
+   u8 delivery_mode:3;
+   u8 dest_mode:1;
+   u8 delivery_status:1;
+   u8 polarity:1;
+   u8 remote_irr:1;
+   u8 trig_mode:1;
+   u8 mask:1;
+   u8 reserve:7;
+   u8 reserved[4];
+   u8 dest_id;
+   } fields;
+};
+
 #endif /* __KVM_TYPES_H__ */
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index e85a2bc..b6530e9 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -85,7 +85,7 @@ static unsigned long ioapic_read_indirect(struct kvm_ioapic 
*ioapic,
 
 static void ioapic_service(struct kvm_ioapic *ioapic, unsigned int idx)
 {
-   union ioapic_redir_entry *pent;
+   union kvm_ioapic_redirect_entry *pent;
 
pent = &ioapic->redirtbl[idx];
 
@@ -277,7 +277,7 @@ void kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, 
int level)
 {
u32 old_irr = ioapic->irr;
u32 mask = 1 << irq;
-   union ioapic_redir_entry entry;
+   union kvm_ioapic_redirect_entry entry;
 
if (irq >= 0 && irq < IOAPIC_NUM_PINS) {
entry = ioapic->redirtbl[irq];
@@ -296,7 +296,7 @@ void kvm_ioapic_set_irq(struct kvm_ioapic *ioapic, int irq, 
int level)
 static void __kvm_ioapic_update_eoi(struct kvm_ioapic *ioapic, int gsi,
int trigger_mode)
 {
-   union ioapic_redir_entry *ent;
+   union kvm_ioapic_redirect_entry *ent;
 
ent = &ioapic->redirtbl[gsi];
 
diff --git a/virt/kvm/ioapic.h b/virt/kvm/ioapic.h
index 49c9581..ee5b0bd 100644
--- a/virt/kvm/ioapic.h
+++ b/virt/kvm/ioapic.h
@@ -40,22 +40,7 @@ struct kvm_ioapic {
u32 id;
u32 irr;
u32 pad;
-   union ioapic_redir_entry {
-   u64 bits;
-   struct {
-   u8 vector;
-   u8 delivery_mode:3;
-   u8 dest_mode:1;
-   u8 delivery_status:1;
-   u8 polarity:1;
-   u8 remote_irr:1;
-   u8 trig_mode:1;
-   u8 mask:1;
-   u8 reserve:7;
-   u8 reserved[4];
-   u8 dest_id;
-   } fields;
-   } redirtbl[IOAPIC_NUM_PINS];
+   union kvm_ioapic_redirect_entry redirtbl[IOAPIC_NUM_PINS];
struct kvm_io_device dev;
struct kvm *kvm;
void (*ack_notifier)(void *opaque, int irq);
-- 
1.5.4.5

--
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

[PATCH 3/7] KVM: Improve MSI dispatch function

[Sheng Yang]

Prepare to merge with kvm_set_irq().

Signed-off-by: Sheng Yang 
---
 virt/kvm/kvm_main.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 3bbb59f..fb2d639 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -87,7 +87,7 @@ static bool kvm_rebooting;
 #ifdef KVM_CAP_DEVICE_ASSIGNMENT
 
 #ifdef CONFIG_X86
-static void assigned_device_msi_dispatch(struct kvm_assigned_dev_kernel *dev)
+static void assigned_device_msi_dispatch(struct kvm_assigned_dev_kernel *dev, 
u32 gsi)
 {
int vcpu_id;
struct kvm_vcpu *vcpu;
@@ -98,7 +98,7 @@ static void assigned_device_msi_dispatch(struct 
kvm_assigned_dev_kernel *dev)
 
BUG_ON(!ioapic);
 
-   gsi_entry = kvm_find_gsi_route_entry(dev->kvm, dev->guest_irq);
+   gsi_entry = kvm_find_gsi_route_entry(dev->kvm, gsi);
if (!gsi_entry) {
printk(KERN_WARNING "kvm: fail to find correlated gsi entry\n");
return;
@@ -145,7 +145,7 @@ static void assigned_device_msi_dispatch(struct 
kvm_assigned_dev_kernel *dev)
}
 }
 #else
-static void assigned_device_msi_dispatch(struct kvm_assigned_dev_kernel *dev) 
{}
+static void assigned_device_msi_dispatch(struct kvm_assigned_dev_kernel *dev, 
u32 gsi) {}
 #endif
 
 static struct kvm_assigned_dev_kernel *kvm_find_assigned_dev(struct list_head 
*head,
@@ -180,7 +180,7 @@ static void kvm_assigned_dev_interrupt_work_handler(struct 
work_struct *work)
assigned_dev->guest_irq, 1);
else if (assigned_dev->irq_requested_type &
KVM_ASSIGNED_DEV_GUEST_MSI) {
-   assigned_device_msi_dispatch(assigned_dev);
+   assigned_device_msi_dispatch(assigned_dev, 
assigned_dev->guest_irq);
enable_irq(assigned_dev->host_irq);
assigned_dev->host_irq_disabled = false;
}
-- 
1.5.4.5

--
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

[PATCH 0/7][v5] GSI route layer for MSI/MSI-X

[Sheng Yang]

Update from v4:
Addressed Marcelo's comments on the first patch, as well as separate bitmap
optimize patchset, which would be posted after this one is checked in.

--
regards
Yang, Sheng
--
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

[ kvm-Bugs-2493498 ] Link to latest virtio drivers dead in wiki

[SourceForge.net]

Bugs item #2493498, was opened at 2009-01-08 11:34
Message generated for change (Comment added) made by thekozmo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2493498&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kenni (kelu6)
Assigned to: Nobody/Anonymous (nobody)
Summary: Link to latest virtio drivers dead in wiki

Initial Comment:
I've previously had success using the latest Virtio Windows drivers from the 
KVM Wiki instead of the latest (and older) version from Sourceforge on Windows 
Vista and 2008.

The following page in the wiki links to both the new drivers and the older 
drivers currently in Sourceforge:
http://kvm.qumranet.com/kvmwiki/VirtioWindowsDrivers

However, the link to the latest drivers has been dead for at least two weeks, 
can someone please fix it or upload the latest version to Sourceforge?

Is there any reason why the latest drivers wasn't uploaded to Sourceforge in 
the first place?

--

Comment By: Dor Laor (thekozmo)
Date: 2009-01-08 12:31

Message:
The people.qumranet.com was blocked.
I updated the new location for latest pv win drivers in the wiki.
10x

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2493498&group_id=180599
--
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

[ kvm-Bugs-2493498 ] Link to latest virtio drivers dead in wiki

[SourceForge.net]

Bugs item #2493498, was opened at 2009-01-08 10:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2493498&group_id=180599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Kenni (kelu6)
Assigned to: Nobody/Anonymous (nobody)
Summary: Link to latest virtio drivers dead in wiki

Initial Comment:
I've previously had success using the latest Virtio Windows drivers from the 
KVM Wiki instead of the latest (and older) version from Sourceforge on Windows 
Vista and 2008.

The following page in the wiki links to both the new drivers and the older 
drivers currently in Sourceforge:
http://kvm.qumranet.com/kvmwiki/VirtioWindowsDrivers

However, the link to the latest drivers has been dead for at least two weeks, 
can someone please fix it or upload the latest version to Sourceforge?

Is there any reason why the latest drivers wasn't uploaded to Sourceforge in 
the first place?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2493498&group_id=180599
--
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 05/10] KVM: Merge MSI handling to kvm_set_irq

[Sheng Yang]

On Thursday 08 January 2009 05:39:32 Marcelo Tosatti wrote:
> On Wed, Jan 07, 2009 at 06:42:41PM +0800, Sheng Yang wrote:
> > Using kvm_set_irq to handle all interrupt injection.
> >
> > Signed-off-by: Sheng Yang 
> > ---
> >  include/linux/kvm_host.h |2 +-
> >  virt/kvm/irq_comm.c  |   79
> > +++-- virt/kvm/kvm_main.c  | 
> >  79 +++--- 3 files changed, 81
> > insertions(+), 79 deletions(-)
> >
> > +static void gsi_dispatch(struct kvm *kvm, u32 gsi)
> > +{
> > +   int vcpu_id;
> > +   struct kvm_vcpu *vcpu;
> > +   struct kvm_ioapic *ioapic = ioapic_irqchip(kvm);
> > +   struct kvm_gsi_route_entry *gsi_entry;
> > +   int dest_id, vector, dest_mode, trig_mode, delivery_mode;
> > +   u32 deliver_bitmask;
> > +
> > +   BUG_ON(!ioapic);
> > +
> > +   gsi_entry = kvm_find_gsi_route_entry(kvm, gsi);
> > +   if (!gsi_entry) {
> > +   printk(KERN_WARNING "kvm: fail to find correlated gsi entry\n");
> > +   return;
> > +   }
> > +
> > +#ifdef CONFIG_X86
> > +   if (gsi_entry->type & KVM_GSI_ROUTE_MSI) {
> > +   dest_id = (gsi_entry->msi.address_lo & MSI_ADDR_DEST_ID_MASK)
> > +   >> MSI_ADDR_DEST_ID_SHIFT;
> > +   vector = (gsi_entry->msi.data & MSI_DATA_VECTOR_MASK)
> > +   >> MSI_DATA_VECTOR_SHIFT;
> > +   dest_mode = test_bit(MSI_ADDR_DEST_MODE_SHIFT,
> > +   (unsigned long *)&gsi_entry->msi.address_lo);
> > +   trig_mode = test_bit(MSI_DATA_TRIGGER_SHIFT,
> > +   (unsigned long *)&gsi_entry->msi.data);
> > +   delivery_mode = test_bit(MSI_DATA_DELIVERY_MODE_SHIFT,
> > +   (unsigned long *)&gsi_entry->msi.data);
> > +   deliver_bitmask = kvm_ioapic_get_delivery_bitmask(ioapic,
> > +   dest_id, dest_mode);
> > +   /* IOAPIC delivery mode value is the same as MSI here */
> > +   switch (delivery_mode) {
>
> Sheng,
>
> This code seems to ignore the RH bit (MSI_ADDR_REDIRECTION_SHIFT):
>
> 4.Destination mode (DM) — This bit indicates whether the Destination
> ID field should be interpreted as logical or physical APIC ID for
> delivery of the lowest priority interrupt. If RH is 1 and DM is 0,
> the Destination ID field is in physical destination mode and only the
> processor in the system that has the matching APIC ID is considered
> for delivery of that interrupt (this means no re-direction). If RH
> is 1 and DM is 1, the Destination ID Field is interpreted as in
> logical destination mode and the redirection is limited to only those
> processors that are part of the logical group of processors based
> on the processor’s logical APIC ID and the Destination ID field
> in the message. The logical group of processors consists of those
> identified by matching the 8-bit Destination ID with the logical
> destination identified by the Destination Format Register and the
> Logical Destination Register in each local APIC.
>
> Is that intentional?

Um... Partly... For RH bits is almost always 1... OK, I would add another 
patch for this bit later.

-- 
regards
Yang, Sheng
--
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