Re: [PATCH] kvm tools: Process virito blk requests in separate thread
On Tue, Jun 05, 2012 at 08:47:17AM +0800, Asias He wrote: I must admit I don't understand this code ;) The data get read into stack variable forever? The data we read itself is not interesting at all. virtio_blk_thread() sleeps on the eventfd bdev-io_efd until notify_vq() writes something to wake it up. Ah, thanks for explanation, Asias. Cyrill -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PULL 00/20 1.2] kvm updates
On 06/05/2012 04:58 AM, Anthony Liguori wrote: On 06/05/2012 08:52 AM, Andreas Färber wrote: Am 04.06.2012 07:46, schrieb Anthony Liguori: On 05/22/2012 12:37 AM, Avi Kivity wrote: Please pull from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Pulled. Thanks. This broke the ppc build. Guys, why wasn't this tested? There's only three KVM targets to test compared to the 14 I'm struggling with... Is build bot running against uq/master? If it's not, maybe we should add it to build bot to catch this sort of thing. A build bot is overkill. I usually do a full build (and autotest), don't know how this was missed. -- 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/2] kvm tools: Increase AIO_MAX to 256
On Mon, 4 Jun 2012, Asias He wrote: The queue size for virtio_blk is 256 and AIO_MAX is 32, we might be short of available aio events if guest issues 32 requests simultaneously. Following error is observed when guest running stressed I/O workload. Info: disk_image__read error: total=-11 To fix this, let's increase the aio events limit. Signed-off-by: Asias He asias.he...@gmail.com --- tools/kvm/disk/core.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/kvm/disk/core.c b/tools/kvm/disk/core.c index ed338e7..d1d2d59 100644 --- a/tools/kvm/disk/core.c +++ b/tools/kvm/disk/core.c @@ -6,7 +6,7 @@ #include sys/eventfd.h #include sys/poll.h -#define AIO_MAX 32 +#define AIO_MAX 256 int debug_iodelay; Is there any downside to bumping up the limit? Ingo? -- 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/2] kvm tools: Restart io_submit if it returns EAGAIN
On Mon, 4 Jun 2012, Asias He wrote: Keep trying if io_submit returns EAGAIN. No need to fail the request. Signed-off-by: Asias He asias.he...@gmail.com Applied, thanks! -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PULL 00/20 1.2] kvm updates
On 05.06.2012, at 09:42, Avi Kivity a...@redhat.com wrote: On 06/05/2012 04:58 AM, Anthony Liguori wrote: On 06/05/2012 08:52 AM, Andreas Färber wrote: Am 04.06.2012 07:46, schrieb Anthony Liguori: On 05/22/2012 12:37 AM, Avi Kivity wrote: Please pull from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Pulled. Thanks. This broke the ppc build. Guys, why wasn't this tested? There's only three KVM targets to test compared to the 14 I'm struggling with... Is build bot running against uq/master? If it's not, maybe we should add it to build bot to catch this sort of thing. A build bot is overkill. I usually do a full build (and autotest), don't know how this was missed. Not sure why it would be overkill. We have build bots running on more exotic hw (ppc and s390) with kvm available for that exact purpose. They're running either way - all we need to do is enable uq/master and we catch these before the next pull request :). Alex -- 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 tools: Process virito blk requests in separate thread
On Tue, Jun 5, 2012 at 4:03 AM, Asias He asias.he...@gmail.com wrote: On Tue, Jun 5, 2012 at 12:07 AM, Sasha Levin levinsasha...@gmail.com wrote: On Mon, 2012-06-04 at 23:40 +0800, Asias He wrote: All blk requests are processed in notify_vq() which is in the context of ioeventfd thread: ioeventfd__thread(). The processing in notify_vq() may take a long time to complete and all devices share the single ioeventfd thead, so this might block other device's notify_vq() being called and starve other devices. We're using native vectored AIO for for processing blk requests, so I'm not certain if theres any point in giving the blk device it's own thread for handling that. We discussed this last year. Search the same subject. Pekka suggested improving the thead pool API to support dedicated thead support. I'd prefer to merge this patch for now since that support is till not there. Recently, I added some debug code to see how many loops virtio_blk_do_io() will do until it finishes the processing. I am seeing something like this: Info: virtio_blk_do_io max_nr_loop=8427 The processing takes a very long time. Ingo, any comments on the thread-per-blk-device model? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] kvm tools: Increase AIO_MAX to 256
On Tue, Jun 5, 2012 at 3:59 PM, Pekka Enberg penb...@kernel.org wrote: On Mon, 4 Jun 2012, Asias He wrote: The queue size for virtio_blk is 256 and AIO_MAX is 32, we might be short of available aio events if guest issues 32 requests simultaneously. Following error is observed when guest running stressed I/O workload. Info: disk_image__read error: total=-11 To fix this, let's increase the aio events limit. Signed-off-by: Asias He asias.he...@gmail.com --- tools/kvm/disk/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/kvm/disk/core.c b/tools/kvm/disk/core.c index ed338e7..d1d2d59 100644 --- a/tools/kvm/disk/core.c +++ b/tools/kvm/disk/core.c @@ -6,7 +6,7 @@ #include sys/eventfd.h #include sys/poll.h -#define AIO_MAX 32 +#define AIO_MAX 256 int debug_iodelay; Is there any downside to bumping up the limit? Ingo? We can have 0x1 aio requests by default which is way much larger than 256. And we can also increase this limit through /proc/sys/fs/aio-max-nr. -- fs/aio.c unsigned long aio_max_nr = 0x1; /* system wide maximum number of aio requests */ -- -- Asias He -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PULL 00/20 1.2] kvm updates
On 2012-06-05 10:10, Alexander Graf wrote: On 05.06.2012, at 09:42, Avi Kivity a...@redhat.com wrote: On 06/05/2012 04:58 AM, Anthony Liguori wrote: On 06/05/2012 08:52 AM, Andreas Färber wrote: Am 04.06.2012 07:46, schrieb Anthony Liguori: On 05/22/2012 12:37 AM, Avi Kivity wrote: Please pull from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Pulled. Thanks. This broke the ppc build. Guys, why wasn't this tested? There's only three KVM targets to test compared to the 14 I'm struggling with... Is build bot running against uq/master? If it's not, maybe we should add it to build bot to catch this sort of thing. A build bot is overkill. I usually do a full build (and autotest), don't know how this was missed. Not sure why it would be overkill. We have build bots running on more exotic hw (ppc and s390) with kvm available for that exact purpose. They're running either way - all we need to do is enable uq/master and we catch these before the next pull request :). I think this makes some sense. uq/master is supposed to be the staging branch for generic and (at least) x86 kvm changes in QEMU. So it should cover at least their builds. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- 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] KVM: Fix PCI header check on device assignment
The masking was wrong (must have been 0x7f), and there is no need to
re-read the value as pci_setup_device already does this for us.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43339
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
virt/kvm/assigned-dev.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/assigned-dev.c b/virt/kvm/assigned-dev.c
index 01f572c..b1e091a 100644
--- a/virt/kvm/assigned-dev.c
+++ b/virt/kvm/assigned-dev.c
@@ -635,7 +635,6 @@ static int kvm_vm_ioctl_assign_device(struct kvm *kvm,
int r = 0, idx;
struct kvm_assigned_dev_kernel *match;
struct pci_dev *dev;
- u8 header_type;
if (!(assigned_dev-flags KVM_DEV_ASSIGN_ENABLE_IOMMU))
return -EINVAL;
@@ -668,8 +667,7 @@ static int kvm_vm_ioctl_assign_device(struct kvm *kvm,
}
/* Don't allow bridges to be assigned */
- pci_read_config_byte(dev, PCI_HEADER_TYPE, header_type);
- if ((header_type PCI_HEADER_TYPE) != PCI_HEADER_TYPE_NORMAL) {
+ if (dev-hdr_type != PCI_HEADER_TYPE_NORMAL) {
r = -EPERM;
goto out_put;
}
--
1.7.3.4
--
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: Has any work 3.3 kvm-kmod for rhel 6.2 kernel successfully?
On 2012-06-05 06:22, ya su wrote:
Jan:
sorry for late response of your suggestion.
I have found the patch which produce this problem, it comes from
this one: 7850ac5420803996e2960d15b924021f28e0dffc.
I change as the following, it works fine.
diff -ur -i kvm-kmod-3.4/x86/kvm_main.c kvm-kmod-3.4-fix/x86/kvm_main.c
--- kvm-kmod-3.4/x86/kvm_main.c 2012-05-21 23:43:02.0 +0800
+++ kvm-kmod-3.4-fix/x86/kvm_main.c 2012-06-05 12:19:37.780136969 +0800
@@ -1525,8 +1525,8 @@
if (memslot memslot-dirty_bitmap) {
unsigned long rel_gfn = gfn - memslot-base_gfn;
- if (!test_and_set_bit_le(rel_gfn, memslot-dirty_bitmap))
- memslot-nr_dirty_pages++;
+ __set_bit_le(rel_gfn, memslot-dirty_bitmap);
+ memslot-nr_dirty_pages++;
}
}
~
I think the root cause maybe: the acton of clear dirty_bitmap
don't sync with that of set nr_dirty_pages=0.
but I don't realize why it works fine in new kernel.
Takuya, any idea why this change could make a difference when running
3.4 kvm code on an older host kernel?
Jan
Regards.
Suya.
2012/4/16 Jan Kiszka jan.kis...@siemens.com:
On 2012-04-16 16:34, ya su wrote:
I first notice 3.3 release notes, it says it can compile against
2.6.32-40, so I think it can work with 2.6.32, then I change it with
rhel 2.6.32 kernel.
The problem is that the RHEL 2.6.32 kernel has nothing to do with a
standard 2.6.32 as too many features were ported back. So the version
number based feature checks fail as you noticed.
We could adapt kvm-kmod to detect that it is a RHEL kernel (there is
surely some define), but it requires going through all the relevant
features carefully.
I just re-change orginal kvm-kmod 3.3 with rhel 2.6.32, only to change
compile redefination errors, but the problem remains the same. the
patch attached.
I don't go through git commits, as so many changes from 2.6.32 to 3.3 in
kernel.
I think the problem may come from memory change notification.
The approach to resolve this could be to identify backported features
based on the build breakage or runtime anomalies, then analyze the
kvm-kmod history for changes that wrapped those features, and finally
adjust all affected code blocks. I'm open for patches and willing to
support you on questions, but I can't work on this myself.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PULL 00/20 1.2] kvm updates
On 06/05/2012 03:42 PM, Avi Kivity wrote: On 06/05/2012 04:58 AM, Anthony Liguori wrote: On 06/05/2012 08:52 AM, Andreas Färber wrote: Am 04.06.2012 07:46, schrieb Anthony Liguori: On 05/22/2012 12:37 AM, Avi Kivity wrote: Please pull from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Pulled. Thanks. This broke the ppc build. Guys, why wasn't this tested? There's only three KVM targets to test compared to the 14 I'm struggling with... Is build bot running against uq/master? If it's not, maybe we should add it to build bot to catch this sort of thing. A build bot is overkill. I usually do a full build (and autotest), don't know how this was missed. Note that this error is specific to KVM on PowerPC. It doesn't affect qemu-system-ppc64 built on an x86_64 host. 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: [Qemu-devel] [PULL 00/20 1.2] kvm updates
On 06/05/2012 12:02 PM, Anthony Liguori wrote: On 06/05/2012 03:42 PM, Avi Kivity wrote: On 06/05/2012 04:58 AM, Anthony Liguori wrote: On 06/05/2012 08:52 AM, Andreas Färber wrote: Am 04.06.2012 07:46, schrieb Anthony Liguori: On 05/22/2012 12:37 AM, Avi Kivity wrote: Please pull from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Pulled. Thanks. This broke the ppc build. Guys, why wasn't this tested? There's only three KVM targets to test compared to the 14 I'm struggling with... Is build bot running against uq/master? If it's not, maybe we should add it to build bot to catch this sort of thing. A build bot is overkill. I usually do a full build (and autotest), don't know how this was missed. Note that this error is specific to KVM on PowerPC. It doesn't affect qemu-system-ppc64 built on an x86_64 host. Ah, okay. In any case I take back my comment about overkill. An extra buildbot run is cheap and overkill is better than underkill. -- 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: AMD KVM Pci Passthrough reports device busy
Hello Alex, thanks for your efforts! Maybe, you already know that I'm suffering the same problem :-( with a GA-990XA-UD3 (990X chipset). On Mon, 04 Jun 2012 21:44:05 -0600 Alex Williamson alex.william...@redhat.com wrote: [...] I have a setup with an AMD 990FX system and a spare PVR-350 card that I installed to reproduce. The sad answer is that it's nearly impossible to assign PCI devices on these systems due to the aliasing of devices below the PCIe-to-PCI bridge (PCIe devices are much, much easier to assign). If you boot with amd_iommu_dump, you'll see some output like this: AMD-Vi: DEV_ALIAS_RANGE devid: 05:00.0 flags: 00 devid_to: 00:14.4 AMD-Vi: DEV_RANGE_ENDdevid: 05:1f.7 here: AMD-Vi: DEV_ALIAS_RANGE devid: 06:00.0 flags: 00 devid_to: 00:14.4 AMD-Vi: DEV_RANGE_END devid: 06:1f.7 This means according to your description, the following devices have to be unbound here, too (:06:07.0 is the device I want to passthrough): :00:14.0 - ../../../../devices/pci:00/:00:14.0 :00:14.1 - ../../../../devices/pci:00/:00:14.1 :00:14.2 - ../../../../devices/pci:00/:00:14.2 :00:14.3 - ../../../../devices/pci:00/:00:14.3 :00:14.4 - ../../../../devices/pci:00/:00:14.4 :00:14.5 - ../../../../devices/pci:00/:00:14.5 :06:07.0 - ../../../../devices/pci:00/:00:14.4/:06:07.0 These are the following additional devices: 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller (rev 42) 00:14.1 IDE interface: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 IDE Controller (rev 40) (prog-if 8a [Master SecP PriP]) 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40) 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 LPC host controller (rev 40) 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge (rev 40) (prog-if 01 [Subtractive decode]) 00:14.5 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI2 Controller (prog-if 10 [OHCI]) Among them is the sound device and the USB device - no good idea to disable them on a desktop. Disabling 00:14.1 seems to be possible (rmmod pata_atiixp works), but I'm getting errors after rebooting the system (the filesystems haven't been cleanly unmounted during shutdown). Anyway, I would have tested it, but I'm getting a compile error while compiling qemu. It complains about missing pci/header.h while processing hw/vfio_pci.c:49:24. I can't find any pci/header.h. Where should it come from? [...] The downside is that VFIO is strict about multifunction devices supporting ACS to prevent peer-to-peer between domains, so will require all of the 14.x devices to be bound to pci-stub as well. On my system, this includes an smbus controller, audio device, lpc controller, and usb device. If AMD could confirm this device doesn't allow peer-to-peer between functions, we could relax this requirement a bit. Please Joerg, could you take a look at this problem? Thanks, kind regards, Andreas -- 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 v2 6/7] kvm,x86: RCU based table free
On Mon, 4 Jun 2012, Nikunj A. Dadhania wrote:
From: Peter Zijlstra a.p.zijls...@chello.nl
get_user_pages_fast() depends on the IPI to hold off page table
teardown while they are locklessly walked with interrupts disabled.
If a vcpu were to be preempted while in this critical section, another
vcpu tearing down page tables would go ahead and destroy them. when
the preempted vcpu resumes it then touches the freed pages.
Using HAVE_RCU_TABLE_FREE:
By using call_rcu_sched() to free the page-tables you'd need to
receive and process at least one tick on the woken up cpu after the
freeing, but since the in-progress gup_fast() will have IRQs disabled
this will be delayed.
http://article.gmane.org/gmane.linux.kernel/1290539
Tested-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com
Signed-off-by: Nikunj A. Dadhania nik...@linux.vnet.ibm.com
arch/powerpc/include/asm/pgalloc.h |1 +
arch/s390/mm/pgtable.c |1 +
arch/sparc/include/asm/pgalloc_64.h |1 +
arch/x86/mm/pgtable.c |6 +++---
include/asm-generic/tlb.h |9 +
mm/memory.c |7 +++
6 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/pgalloc.h
b/arch/powerpc/include/asm/pgalloc.h
index bf301ac..c33ae79 100644
--- a/arch/powerpc/include/asm/pgalloc.h
+++ b/arch/powerpc/include/asm/pgalloc.h
@@ -49,6 +49,7 @@ static inline void __tlb_remove_table(void *_table)
pgtable_free(table, shift);
}
+#define __tlb_remove_table __tlb_remove_table
#else /* CONFIG_SMP */
static inline void pgtable_free_tlb(struct mmu_gather *tlb, void *table,
unsigned shift)
{
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 6e765bf..7029ed7 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -730,6 +730,7 @@ void __tlb_remove_table(void *_table)
else
free_pages((unsigned long) table, ALLOC_ORDER);
}
+#define __tlb_remove_table __tlb_remove_table
static void tlb_remove_table_smp_sync(void *arg)
{
diff --git a/arch/sparc/include/asm/pgalloc_64.h
b/arch/sparc/include/asm/pgalloc_64.h
index 40b2d7a..d10913a 100644
--- a/arch/sparc/include/asm/pgalloc_64.h
+++ b/arch/sparc/include/asm/pgalloc_64.h
@@ -106,6 +106,7 @@ static inline void __tlb_remove_table(void *_table)
is_page = true;
pgtable_free(table, is_page);
}
+#define __tlb_remove_table __tlb_remove_table
#else /* CONFIG_SMP */
static inline void pgtable_free_tlb(struct mmu_gather *tlb, void *table,
bool is_page)
{
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index 8573b83..34fa168 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -51,21 +51,21 @@ void ___pte_free_tlb(struct mmu_gather *tlb, struct page
*pte)
{
pgtable_page_dtor(pte);
paravirt_release_pte(page_to_pfn(pte));
- tlb_remove_page(tlb, pte);
+ tlb_remove_table(tlb, pte);
}
#if PAGETABLE_LEVELS 2
void ___pmd_free_tlb(struct mmu_gather *tlb, pmd_t *pmd)
{
paravirt_release_pmd(__pa(pmd) PAGE_SHIFT);
- tlb_remove_page(tlb, virt_to_page(pmd));
+ tlb_remove_table(tlb, virt_to_page(pmd));
}
#if PAGETABLE_LEVELS 3
void ___pud_free_tlb(struct mmu_gather *tlb, pud_t *pud)
{
paravirt_release_pud(__pa(pud) PAGE_SHIFT);
- tlb_remove_page(tlb, virt_to_page(pud));
+ tlb_remove_table(tlb, virt_to_page(pud));
}
#endif /* PAGETABLE_LEVELS 3 */
#endif /* PAGETABLE_LEVELS 2 */
diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h
index f96a5b5..9ac30f7 100644
--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -19,6 +19,8 @@
#include asm/pgalloc.h
#include asm/tlbflush.h
+static inline void tlb_remove_page(struct mmu_gather *tlb, struct page
*page);
+
#ifdef CONFIG_HAVE_RCU_TABLE_FREE
/*
* Semi RCU freeing of the page directories.
@@ -60,6 +62,13 @@ struct mmu_table_batch {
extern void tlb_table_flush(struct mmu_gather *tlb);
extern void tlb_remove_table(struct mmu_gather *tlb, void *table);
+#else
+
+static inline void tlb_remove_table(struct mmu_gather *tlb, void *page)
+{
+ tlb_remove_page(tlb, page);
+}
+
#endif
/*
diff --git a/mm/memory.c b/mm/memory.c
index 6105f47..c12685d 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -297,6 +297,13 @@ int __tlb_remove_page(struct mmu_gather *tlb, struct
page *page)
* See the comment near struct mmu_table_batch.
*/
+#ifndef __tlb_remove_table
+static void __tlb_remove_table(void *table)
+{
+ free_page_and_swap_cache(table);
+}
+#endif
+
static void tlb_remove_table_smp_sync(void *arg)
{
/* Simply deliver the interrupt */
I am also interested in introducing HAVE_RCU_TABLE_FREE on x86 for Xen.
Maybe we can pull our efforts together :-)
Giving a look at this patch, it doesn't look like it is introducing
Re: [PATCH v2 6/7] kvm,x86: RCU based table free
On Tue, 5 Jun 2012 11:48:02 +0100, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: I am also interested in introducing HAVE_RCU_TABLE_FREE on x86 for Xen. Maybe we can pull our efforts together :-) Giving a look at this patch, it doesn't look like it is introducing CONFIG_HAVE_RCU_TABLE_FREE anywhere under arch/x86. How is the user supposed to set it? I am doing that in the next patch only for KVM-ParavirtTLB flush, as there is a bug in this implementation that patch [7/7] fixes. Refer following thread for details: http://mid.gmane.org/1337254086.4281.26.camel@twins http://mid.gmane.org/1337273959.4281.62.camel@twins Regards Nikunj -- 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 v2 00/41] postcopy live migration
On 06/04/2012 04:38 PM, Isaku Yamahata wrote: On Mon, Jun 04, 2012 at 08:37:04PM +0800, Anthony Liguori wrote: On 06/04/2012 05:57 PM, Isaku Yamahata wrote: After the long time, we have v2. This is qemu part. The linux kernel part is sent separatedly. Changes v1 - v2: - split up patches for review - buffered file refactored - many bug fixes Espcially PV drivers can work with postcopy - optimization/heuristic Patches 1 - 30: refactoring exsiting code and preparation 31 - 37: implement postcopy itself (essential part) 38 - 41: some optimization/heuristic for postcopy Intro = This patch series implements postcopy live migration.[1] As discussed at KVM forum 2011, dedicated character device is used for distributed shared memory between migration source and destination. Now we can discuss/benchmark/compare with precopy. I believe there are much rooms for improvement. [1] http://wiki.qemu.org/Features/PostCopyLiveMigration Usage = You need load umem character device on the host before starting migration. Postcopy can be used for tcg and kvm accelarator. The implementation depend on only linux umem character device. But the driver dependent code is split into a file. I tested only host page size == guest page size case, but the implementation allows host page size != guest page size case. The following options are added with this patch series. - incoming part command line options -postcopy [-postcopy-flagsflags] where flags is for changing behavior for benchmark/debugging Currently the following flags are available 0: default 1: enable touching page request example: qemu -postcopy -incoming tcp:0: -monitor stdio -machine accel=kvm - outging part options for migrate command migrate [-p [-n] [-m]] URI [prefault forward [prefault backword]] -p: indicate postcopy migration -n: disable background transferring pages: This is for benchmark/debugging -m: move background transfer of postcopy mode prefault forward: The number of forward pages which is sent with on-demand prefault backward: The number of backward pages which is sent with on-demand example: migrate -p -n tcp:dest ip address: migrate -p -n -m tcp:dest ip address: 32 0 TODO - benchmark/evaluation. Especially how async page fault affects the result. I don't mean to beat on a dead horse, but I really don't understand the point of postcopy migration other than the fact that it's possible. It's a lot of code and a new ABI in an area where we already have too much difficulty maintaining our ABI. Without a compelling real world case with supporting benchmarks for why we need postcopy and cannot improve precopy, I'm against merging this. Some new results are available at https://events.linuxfoundation.org/images/stories/pdf/lcjp2012_yamahata_postcopy.pdf It does shows dramatic improvement over pre copy. As stated in the docs, async page faults may help lots of various loads and turn post copy into a viable solution over today's code. In addition, the sort of 'demand pages' approach on the destination can help us for other usages - For example, we can use this implementation to live snapshot VMs w/ RAM (post live migration into a file that leave the source active) and live resume VMs from file w/o reading the entire RAM from disk. I didn't go over the api for the live migration part but IIUC, the only change needed for the live migration 'protocol' is w.r.t guest pages and we need to do it regardless when we'll merge the page ordering optimization. Cheers, Dor precopy assumes that the network bandwidth are wide enough and the number of dirty pages converges. But it doesn't always hold true. - planned migration predictability of total migration time is important - dynamic consolidation In cloud use cases, the resources of physical machine are usually over committed. When physical machine becomes over loaded, some VMs are moved to another physical host to balance the load. precopy can't move VMs promptly. compression makes things worse. - inter data center migration With L2 over L3 technology, it has becoming common to create a virtual data center which actually spans over multi physical data centers. It is useful to migrate VMs over physical data centers as disaster recovery. The network bandwidth between DCs is narrower than LAN case. So precopy assumption wouldn't hold. - In case that network bandwidth might be limited by QoS, precopy assumption doesn't hold. thanks, -- 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 v2 6/7] kvm,x86: RCU based table free
On Tue, 5 Jun 2012, Nikunj A Dadhania wrote: On Tue, 5 Jun 2012 11:48:02 +0100, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: I am also interested in introducing HAVE_RCU_TABLE_FREE on x86 for Xen. Maybe we can pull our efforts together :-) Giving a look at this patch, it doesn't look like it is introducing CONFIG_HAVE_RCU_TABLE_FREE anywhere under arch/x86. How is the user supposed to set it? I am doing that in the next patch only for KVM-ParavirtTLB flush, as there is a bug in this implementation that patch [7/7] fixes. Refer following thread for details: http://mid.gmane.org/1337254086.4281.26.camel@twins http://mid.gmane.org/1337273959.4281.62.camel@twins Thanks, somehow I missed the 7/7 patch. From the Xen POV, your patch is fine because we'll just select PARAVIRT_TLB_FLUSH on CONFIG_XEN (see appended patch for completeness). The main difference between the two approaches is that a kernel with PARAVIRT_TLB_FLUSH and/or CONFIG_XEN enabled is going to have HAVE_RCU_TABLE_FREE even when running on native. Are you proposing this series for 3.5? If not (because it depends on ticketlocks and KVM Paravirt Spinlock patches), could you extract patch 6/7 and 7/7 and send them out separately? I am saying this because Xen needs the HAVE_RCU_TABLE_FREE fix even if pv ticketlock are not accepted. This is an outstanding bug for us unfortunately. --- xen: select PARAVIRT_TLB_FLUSH if SMP At the moment get_user_pages_fast is unsafe on Xen, because it relies on the fact that flush_tlb_others sends an IPI to flush the tlb but xen_flush_tlb_others doesn't send any IPIs and always returns succesfully and immediately. Select PARAVIRT_TLB_FLUSH, that enables an RCU lock to protect this kind of software pagetable walks (also see HAVE_RCU_TABLE_FREE and include/asm-generic/tlb.h). Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index fdce49c..18c9876 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -6,6 +6,7 @@ config XEN bool Xen guest support select PARAVIRT select PARAVIRT_CLOCK + select PARAVIRT_TLB_FLUSH if SMP depends on X86_64 || (X86_32 X86_PAE !X86_VISWS) depends on X86_CMPXCHG X86_TSC help -- 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: [RFC][PATCH] Add support for the GUEST_SMBASE VMCS field for Intel VT-x.
On Sun, May 20, 2012 at 03:39:30PM +0300, Avi Kivity wrote:
On 05/18/2012 12:34 PM, Matthias Lange wrote:
The following patch adds support for the GUEST_SMBASE field. This allows
hypervisors running inside kvm read/write access to this field. I have
tested this to work on a Core i5 machine.
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index 31f180c..6a14720 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -194,6 +194,7 @@ enum vmcs_field {
GUEST_TR_AR_BYTES = 0x4822,
GUEST_INTERRUPTIBILITY_INFO = 0x4824,
GUEST_ACTIVITY_STATE= 0X4826,
+ GUEST_SMBASE= 0x4828,
GUEST_SYSENTER_CS = 0x482A,
HOST_IA32_SYSENTER_CS = 0x4c00,
CR0_GUEST_HOST_MASK = 0x6000,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4ff0ab9..0063743 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -285,6 +285,7 @@ struct __packed vmcs12 {
u32 guest_tr_ar_bytes;
u32 guest_interruptibility_info;
u32 guest_activity_state;
+ u32 guest_smbase;
u32 guest_sysenter_cs;
u32 host_ia32_sysenter_cs;
u32 padding32[8]; /* room for future expansion */
@@ -546,6 +547,7 @@ static unsigned short vmcs_field_to_offset_table[] = {
vmcs12 is an ABI, so you can't insert fields at random. Grab one from
padding32.
Do you mean the ABI defined in the Intel Software Developer's manual 3B? Or is
vmcs12 only an ABI internal to the kvm module?
I understand that my patch is wrong because I need to decrease the size of
padding32. I tested the patch by running Ubuntu 12.04 as the L1 guest and
Tinycore Linux as the L2 guest.
Let me know what you think.
Matthias.
--
Dipl.-Inf. Matthias Lange mla...@sec.t-labs.tu-berlin.de
Security in Telecommunications
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, 10587 Berlin
Phone: +49 - 30 - 8353 58 553
Mobile: +49 - 160 - 587 28 07
Web: http://www.t-labs.tu-berlin.de/sect
--
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/4] kvm-s390: add capability indicating COW support
On 15.05.2012, at 14:38, Christian Borntraeger wrote: On 15/05/12 14:33, Avi Kivity wrote: On 05/15/2012 03:31 PM, Christian Borntraeger wrote: On 15/05/12 14:24, Avi Kivity wrote: Newer systems allow to write-protect the guest backing memory and let the fault be delivered to the host, thus allowing COW. Use a capability bit to tell qemu if that is possible. Asking out of ignorance: who is doing the write protection here? The guest? If so, why is qemu involved? It is about the host doing write protection of guest/user memory (e.g. for dirty pages tracking or KSM) Ok, so why does qemu^Wuserspace need to know about it? By default qemu will use MAP_PRIVATE for guest pages. This will write protect pages and thus break on s390 systems that dont support this feature. Therefore qemu has a hack to always use MAP_SHARED for s390. But MAP_SHARED has other problems (no dirty pages tracking, a lot more swap overhead etc.) With this feature qemu can use the standard qemu alloc if available, otherwise it will use the old s390 hack. I will put you on cc for the qemu patch :-) It'd be nice to have that documented somewhere :). Alex -- 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/4] kvm-s390: KVM_GET/SET_ONEREG for s390
On 15.05.2012, at 14:15, Christian Borntraeger wrote: From: Carsten Otte co...@de.ibm.com This patch enables KVM_CAP_ONE_REG for s390 and implements stubs for KVM_GET/SET_ONE_REG. This is based on the ppc implementation. Signed-off-by: Carsten Otte co...@de.ibm.com Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com One day we should make this be a true generic interface and not let arch specific code handle it all on their own. But for now, it's good as it is :). Acked-by: Alexander Graf ag...@suse.de Alex -- 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 3/4] kvm-s390: epoch difference and TOD programmable field
On 15.05.2012, at 14:15, Christian Borntraeger wrote: From: Carsten Otte co...@de.ibm.com This patch makes vcpu epoch difference and the TOD programmable field accessible from userspace. This is needed in order to implement a couple of instructions that deal with the time of day clock on s390, such as SET CLOCK and for migration. Signed-off-by: Carsten Otte co...@de.ibm.com Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com No complaints here. Acked-by: Alexander Graf ag...@suse.de Alex -- 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 4/4] kvm-s390: onereg for timer related registers
On 15.05.2012, at 14:15, Christian Borntraeger wrote: From: Jason J. herne jjhe...@us.ibm.com Enhance the KVM ONE_REG capability within S390 to allow getting/setting the following special cpu registers: clock comparator and the cpu timer. These are needed for migration. Signed-off-by: Jason J. herne jjhe...@us.ibm.com Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com Any other registers we need to expose to user space while we're at it? :) Acked-by: Alexander Graf ag...@suse.de Alex -- 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 4/4] kvm-s390: onereg for timer related registers
On 05/06/12 14:42, Alexander Graf wrote: On 15.05.2012, at 14:15, Christian Borntraeger wrote: From: Jason J. herne jjhe...@us.ibm.com Enhance the KVM ONE_REG capability within S390 to allow getting/setting the following special cpu registers: clock comparator and the cpu timer. These are needed for migration. Signed-off-by: Jason J. herne jjhe...@us.ibm.com Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com Any other registers we need to expose to user space while we're at it? :) I hope not. Life guest relocation prototyping indicates that we have at least the subset that allows a linux guest to continue. We might need a way for userspace to influence the output of the store system information and store facility list instruction. Dont know, maybe we could use ONEREG even for that purpose. Its on my todo list, but there are too many other things to tidy up. Since this would be interface/ABI I dont want to rush without really understanding what I need for those instruction. Christian -- 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 4/4] kvm-s390: onereg for timer related registers
On 05.06.2012, at 14:57, Christian Borntraeger wrote: On 05/06/12 14:42, Alexander Graf wrote: On 15.05.2012, at 14:15, Christian Borntraeger wrote: From: Jason J. herne jjhe...@us.ibm.com Enhance the KVM ONE_REG capability within S390 to allow getting/setting the following special cpu registers: clock comparator and the cpu timer. These are needed for migration. Signed-off-by: Jason J. herne jjhe...@us.ibm.com Signed-off-by: Christian Borntraeger borntrae...@de.ibm.com Any other registers we need to expose to user space while we're at it? :) I hope not. Life guest relocation prototyping indicates that we have at least the subset that allows a linux guest to continue. We might need a way for userspace to influence the output of the store system information and store facility list instruction. Dont know, maybe we could use ONEREG even for that purpose. Its on my todo list, but there are too many other things to tidy up. Hrm - not sure if ONEREG is the right interface here. These 2 instructions are more similar to CPUID in that they can have multiple leafs with lots of data each. But then again, which parts exactly would user space care about? Since this would be interface/ABI I dont want to rush without really understanding what I need for those instruction. Yup, very good decision :). I was really more thinking of other SIE fields that look obvious. Alex -- 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 v2 6/7] kvm,x86: RCU based table free
On Tue, 2012-06-05 at 18:34 +0530, Nikunj A Dadhania wrote: PeterZ, is 7/7 alright to be picked? Yeah, I guess it is.. I haven't had time to rework my tlb series yet though. But these two patches together should make it work for x86. -- 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: [RFC][PATCH] Add support for the GUEST_SMBASE VMCS field for Intel VT-x.
On 06/05/2012 02:59 PM, Matthias Lange wrote:
On Sun, May 20, 2012 at 03:39:30PM +0300, Avi Kivity wrote:
On 05/18/2012 12:34 PM, Matthias Lange wrote:
The following patch adds support for the GUEST_SMBASE field. This allows
hypervisors running inside kvm read/write access to this field. I have
tested this to work on a Core i5 machine.
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index 31f180c..6a14720 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -194,6 +194,7 @@ enum vmcs_field {
GUEST_TR_AR_BYTES = 0x4822,
GUEST_INTERRUPTIBILITY_INFO = 0x4824,
GUEST_ACTIVITY_STATE= 0X4826,
+ GUEST_SMBASE= 0x4828,
GUEST_SYSENTER_CS = 0x482A,
HOST_IA32_SYSENTER_CS = 0x4c00,
CR0_GUEST_HOST_MASK = 0x6000,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 4ff0ab9..0063743 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -285,6 +285,7 @@ struct __packed vmcs12 {
u32 guest_tr_ar_bytes;
u32 guest_interruptibility_info;
u32 guest_activity_state;
+ u32 guest_smbase;
u32 guest_sysenter_cs;
u32 host_ia32_sysenter_cs;
u32 padding32[8]; /* room for future expansion */
@@ -546,6 +547,7 @@ static unsigned short vmcs_field_to_offset_table[] = {
vmcs12 is an ABI, so you can't insert fields at random. Grab one from
padding32.
Do you mean the ABI defined in the Intel Software Developer's manual 3B? Or is
vmcs12 only an ABI internal to the kvm module?
The latter. We want to be able to live migrate a guest with nested
guests, and if the format of vmcs12 changes, the migration will break.
I understand that my patch is wrong because I need to decrease the size of
padding32. I tested the patch by running Ubuntu 12.04 as the L1 guest and
Tinycore Linux as the L2 guest.
Let me know what you think.
--
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 v2 6/7] kvm,x86: RCU based table free
On Tue, 5 Jun 2012 12:58:32 +0100, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: On Tue, 5 Jun 2012, Nikunj A Dadhania wrote: On Tue, 5 Jun 2012 11:48:02 +0100, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: I am also interested in introducing HAVE_RCU_TABLE_FREE on x86 for Xen. Maybe we can pull our efforts together :-) Giving a look at this patch, it doesn't look like it is introducing CONFIG_HAVE_RCU_TABLE_FREE anywhere under arch/x86. How is the user supposed to set it? I am doing that in the next patch only for KVM-ParavirtTLB flush, as there is a bug in this implementation that patch [7/7] fixes. Refer following thread for details: http://mid.gmane.org/1337254086.4281.26.camel@twins http://mid.gmane.org/1337273959.4281.62.camel@twins Thanks, somehow I missed the 7/7 patch. From the Xen POV, your patch is fine because we'll just select PARAVIRT_TLB_FLUSH on CONFIG_XEN (see appended patch for completeness). Selecting ARCH_HW_WALKS_PAGE_TABLE in place of PARAVIRT_TLB_FLUSH should suffice. The main difference between the two approaches is that a kernel with PARAVIRT_TLB_FLUSH and/or CONFIG_XEN enabled is going to have HAVE_RCU_TABLE_FREE even when running on native. Are you proposing this series for 3.5? If not (because it depends on ticketlocks and KVM Paravirt Spinlock patches), 3.6 I suppose as the merge window is already closed and we are having some discussions on PLE results. could you extract patch 6/7 and 7/7 and send them out separately? I am saying this because Xen needs the HAVE_RCU_TABLE_FREE fix even if pv ticketlock are not accepted. This is an outstanding bug for us unfortunately. PeterZ has a patch in his tlb-unify: mm, x86: Add HAVE_RCU_TABLE_FREE support Implements optional HAVE_RCU_TABLE_FREE support for x86. This is useful for things like Xen and KVM where paravirt tlb flush means the software page table walkers like GUP-fast cannot rely on IRQs disabling like regular x86 can. Cc: Nikunj A Dadhania nik...@linux.vnet.ibm.com Cc: Jeremy Fitzhardinge jer...@goop.org Cc: Avi Kivity a...@redhat.com Signed-off-by: Peter Zijlstra a.p.zijls...@chello.nl http://git.kernel.org/?p=linux/kernel/git/peterz/mmu.git;a=commit;h=8a7e6fa5be9d2645c3394892c870113e6e5d9309 PeterZ, is 7/7 alright to be picked? Regards Nikunj -- 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 v2 6/7] kvm,x86: RCU based table free
On Tue, 5 Jun 2012, Nikunj A Dadhania wrote: On Tue, 5 Jun 2012 12:58:32 +0100, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: On Tue, 5 Jun 2012, Nikunj A Dadhania wrote: On Tue, 5 Jun 2012 11:48:02 +0100, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: I am also interested in introducing HAVE_RCU_TABLE_FREE on x86 for Xen. Maybe we can pull our efforts together :-) Giving a look at this patch, it doesn't look like it is introducing CONFIG_HAVE_RCU_TABLE_FREE anywhere under arch/x86. How is the user supposed to set it? I am doing that in the next patch only for KVM-ParavirtTLB flush, as there is a bug in this implementation that patch [7/7] fixes. Refer following thread for details: http://mid.gmane.org/1337254086.4281.26.camel@twins http://mid.gmane.org/1337273959.4281.62.camel@twins Thanks, somehow I missed the 7/7 patch. From the Xen POV, your patch is fine because we'll just select PARAVIRT_TLB_FLUSH on CONFIG_XEN (see appended patch for completeness). Selecting ARCH_HW_WALKS_PAGE_TABLE in place of PARAVIRT_TLB_FLUSH should suffice. We would also need to select HAVE_RCU_TABLE_FREE, but it could be a good idea, not go through PARAVIRT_TLB_FLUSH. -- 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 v2 6/7] kvm,x86: RCU based table free
On Tue, 5 Jun 2012, Peter Zijlstra wrote: On Tue, 2012-06-05 at 18:34 +0530, Nikunj A Dadhania wrote: PeterZ, is 7/7 alright to be picked? Yeah, I guess it is.. I haven't had time to rework my tlb series yet though. But these two patches together should make it work for x86. Good. Do you think they are OK for 3.5-rc2? Or is it better to wait for 3.6? -- 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 v2 6/7] kvm,x86: RCU based table free
On Tue, 2012-06-05 at 14:26 +0100, Stefano Stabellini wrote: On Tue, 5 Jun 2012, Peter Zijlstra wrote: On Tue, 2012-06-05 at 18:34 +0530, Nikunj A Dadhania wrote: PeterZ, is 7/7 alright to be picked? Yeah, I guess it is.. I haven't had time to rework my tlb series yet though. But these two patches together should make it work for x86. Good. Do you think they are OK for 3.5-rc2? Or is it better to wait for 3.6? I wouldn't rush this stuff, but if you're up for it and can convince Linus that its all peachy you can try ;-) -- 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 v2 6/7] kvm,x86: RCU based table free
On Tue, 5 Jun 2012, Peter Zijlstra wrote: On Tue, 2012-06-05 at 14:26 +0100, Stefano Stabellini wrote: On Tue, 5 Jun 2012, Peter Zijlstra wrote: On Tue, 2012-06-05 at 18:34 +0530, Nikunj A Dadhania wrote: PeterZ, is 7/7 alright to be picked? Yeah, I guess it is.. I haven't had time to rework my tlb series yet though. But these two patches together should make it work for x86. Good. Do you think they are OK for 3.5-rc2? Or is it better to wait for 3.6? I wouldn't rush this stuff, but if you're up for it and can convince Linus that its all peachy you can try ;-) Fair enough, I think I'll let Konrad make this call :-) -- 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 entry failed, hardware error
On 6/4/12 12:28 PM, Johannes Bauer wrote:
On 04.06.2012 10:53, Gleb Natapov wrote:
On Sun, Jun 03, 2012 at 06:25:33PM +0200, Johannes Bauer wrote:
Therefore, I've uploaded the compressed trace.dat file, so you can maybe
have a look why the report tool barfs and interpret it correctly. I
can't figure it out. The trace is here:
http://spornkuller.de/trace.dat.bz2
I can read this trace.
Hm, weird. But good that it works on your side. I get a lot of:
trace-cmd: No such file or directory
bad op token {
failed to read event print fmt for kvm_emulate_insn
version = 6
CPU 0 is empty
You need to install the plugins for trace-cmd:
make install_plugins
you could also try setting:
export TRACE_CMD_PLUGIN_DIR=/path/to/plugins
David
--
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: AMD KVM Pci Passthrough reports device busy
On Tue, 2012-06-05 at 12:39 +0200, Andreas Hartmann wrote: Hello Alex, thanks for your efforts! Maybe, you already know that I'm suffering the same problem :-( with a GA-990XA-UD3 (990X chipset). My system is a GA-990FXA-UD3, so just a slightly different version of the chipset. On Mon, 04 Jun 2012 21:44:05 -0600 Alex Williamson alex.william...@redhat.com wrote: [...] I have a setup with an AMD 990FX system and a spare PVR-350 card that I installed to reproduce. The sad answer is that it's nearly impossible to assign PCI devices on these systems due to the aliasing of devices below the PCIe-to-PCI bridge (PCIe devices are much, much easier to assign). If you boot with amd_iommu_dump, you'll see some output like this: AMD-Vi: DEV_ALIAS_RANGEdevid: 05:00.0 flags: 00 devid_to: 00:14.4 AMD-Vi: DEV_RANGE_END devid: 05:1f.7 here: AMD-Vi: DEV_ALIAS_RANGE devid: 06:00.0 flags: 00 devid_to: 00:14.4 AMD-Vi: DEV_RANGE_END devid: 06:1f.7 This means according to your description, the following devices have to be unbound here, too (:06:07.0 is the device I want to passthrough): :00:14.0 - ../../../../devices/pci:00/:00:14.0 :00:14.1 - ../../../../devices/pci:00/:00:14.1 :00:14.2 - ../../../../devices/pci:00/:00:14.2 :00:14.3 - ../../../../devices/pci:00/:00:14.3 :00:14.4 - ../../../../devices/pci:00/:00:14.4 :00:14.5 - ../../../../devices/pci:00/:00:14.5 :06:07.0 - ../../../../devices/pci:00/:00:14.4/:06:07.0 Yep. These are the following additional devices: 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller (rev 42) 00:14.1 IDE interface: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 IDE Controller (rev 40) (prog-if 8a [Master SecP PriP]) 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40) 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 LPC host controller (rev 40) 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge (rev 40) (prog-if 01 [Subtractive decode]) 00:14.5 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI2 Controller (prog-if 10 [OHCI]) My system shows this for lspci -n -s 14. 00:14.0 0c05: 1002:4385 (rev 42) 00:14.2 0403: 1002:4383 (rev 40) 00:14.3 0601: 1002:439d (rev 40) 00:14.4 0604: 1002:4384 (rev 40) 00:14.5 0c03: 1002:4399 Can you confirm yours matches and fill in 14.1 so we have the vendor:device IDs for these. Among them is the sound device and the USB device - no good idea to disable them on a desktop. You can always blacklist drivers if the device is unique or unbind devices in an rc.local type script. I'm hoping that Joerg or someone else from AMD can tell us this devices does not allow internal peer-to-peer between functions. Then we can add it to the device specific ACS checks and you wouldn't need to worry about displacing all the other 14.x functions. Disabling 00:14.1 seems to be possible (rmmod pata_atiixp works), but I'm getting errors after rebooting the system (the filesystems haven't been cleanly unmounted during shutdown). Did you have a disk off that controller? My system doesn't expose function 1, but is the same otherwise. Anyway, I would have tested it, but I'm getting a compile error while compiling qemu. It complains about missing pci/header.h while processing hw/vfio_pci.c:49:24. I can't find any pci/header.h. Where should it come from? It is from pciutils-devel for me. I'll see what I'm getting out of there and try to remove it. The downside is that VFIO is strict about multifunction devices supporting ACS to prevent peer-to-peer between domains, so will require all of the 14.x devices to be bound to pci-stub as well. On my system, this includes an smbus controller, audio device, lpc controller, and usb device. If AMD could confirm this device doesn't allow peer-to-peer between functions, we could relax this requirement a bit. Please Joerg, could you take a look at this problem? Joerg, the question is whether the multifunction device above allows peer-to-peer between functions that could bypass the iommu. If not, we can make it the first entry in device specific acs enabled function I proposed: https://lkml.org/lkml/2012/5/30/438 and it would greatly simplify assigning PCI devices on these systems with VFIO. Thanks, Alex -- 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
[GIT PULL] KVM fix for 3.5-rc1
Linus, Please pull from git://git.kernel.org/pub/scm/virt/kvm/kvm.git master to receive a one-liner fix for a buffer overflow: KVM: Fix buffer overflow in kvm_set_irq() (2012-06-05 16:39:58 +0300) Avi Kivity (1): KVM: Fix buffer overflow in kvm_set_irq() virt/kvm/irq_comm.c |1 + 1 file changed, 1 insertion(+) -- 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] PCI: Mark INTx masking support of Chelsio T310 10GbE NIC as broken
On 2012-05-25 16:02, Jan Kiszka wrote:
According to Alexey, the T310 does not properly support INTx masking as
it fails to keep the PCI_STATUS_INTERRUPT bit updated once the interrupt
is masked. Mark this adapter as broken so that pci_intx_mask_supported
won't report it as compatible.
Reported-by: Alexey Kardashevskiy a...@ozlabs.ru
Signed-off-by: Jan Kiszka jan.kis...@web.de
---
Alexey, please test if this catches your case correctly.
Alexey? Ping for testing.
Jan
drivers/pci/pci.c|3 +++
drivers/pci/quirks.c | 12
include/linux/pci.h |2 ++
3 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 8f16900..3a1aeb5 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2876,6 +2876,9 @@ bool pci_intx_mask_supported(struct pci_dev *dev)
bool mask_supported = false;
u16 orig, new;
+ if (dev-broken_intx_masking)
+ return false;
+
pci_cfg_access_lock(dev);
pci_read_config_word(dev, PCI_COMMAND, orig);
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 2a75216..151e174 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -2929,6 +2929,18 @@ static void __devinit disable_igfx_irq(struct pci_dev
*dev)
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x0102, disable_igfx_irq);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x010a, disable_igfx_irq);
+/*
+ * Some devices may pass our check in pci_intx_mask_supported if
+ * PCI_COMMAND_INTX_DISABLE works though they actually do not properly
+ * support this feature.
+ */
+static void __devinit quirk_broken_intx_masking(struct pci_dev *dev)
+{
+ dev-broken_intx_masking = 1;
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, 0x0010,
+ quirk_broken_intx_masking);
+
static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
struct pci_fixup *end)
{
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 17b7b5b..c7cfd73 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -324,6 +324,8 @@ struct pci_dev {
unsigned intis_hotplug_bridge:1;
unsigned int__aer_firmware_first_valid:1;
unsigned int__aer_firmware_first:1;
+ unsigned intbroken_intx_masking:1; /* device's INTx masking
+support is not working */
pci_dev_flags_t dev_flags;
atomic_tenable_cnt; /* pci_enable_device has been called */
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
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/8] Cleanup for virtio/* and disk/*
Asias He (8): kvm tools: Code cleanup for virtio/9p.c kvm tools: Code cleanup for virtio/balloon.c kvm tools: Code cleanup for virtio/blk.c kvm tools: Code cleanup for virtio/console.c kvm tools: Code cleanup for virtio/net.c kvm tools: Code cleanup for disk/core.c kvm tools: Code cleanup for disk/qcow.c kvm tools: Code cleanup for disk/raw.c tools/kvm/disk/core.c | 23 ++ tools/kvm/disk/qcow.c | 16 ++-- tools/kvm/disk/raw.c |2 +- tools/kvm/virtio/9p.c | 58 +--- tools/kvm/virtio/balloon.c |6 ++--- tools/kvm/virtio/blk.c | 28 +++-- tools/kvm/virtio/console.c |6 ++--- tools/kvm/virtio/net.c |8 +++--- 8 files changed, 75 insertions(+), 72 deletions(-) -- 1.7.10.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
[PATCH 1/8] kvm tools: Code cleanup for virtio/9p.c
Signed-off-by: Asias He asias.he...@gmail.com
---
tools/kvm/virtio/9p.c | 58 -
1 file changed, 28 insertions(+), 30 deletions(-)
diff --git a/tools/kvm/virtio/9p.c b/tools/kvm/virtio/9p.c
index 3ef1a5f..4108e02 100644
--- a/tools/kvm/virtio/9p.c
+++ b/tools/kvm/virtio/9p.c
@@ -393,22 +393,22 @@ static void virtio_p9_fill_stat(struct p9_dev *p9dev,
struct stat *st, struct p9_stat_dotl *statl)
{
memset(statl, 0, sizeof(*statl));
- statl-st_mode = st-st_mode;
- statl-st_nlink = st-st_nlink;
- statl-st_uid = st-st_uid;
- statl-st_gid = st-st_gid;
- statl-st_rdev = st-st_rdev;
- statl-st_size = st-st_size;
- statl-st_blksize = st-st_blksize;
- statl-st_blocks = st-st_blocks;
- statl-st_atime_sec = st-st_atime;
- statl-st_atime_nsec = st-st_atim.tv_nsec;
- statl-st_mtime_sec = st-st_mtime;
- statl-st_mtime_nsec = st-st_mtim.tv_nsec;
- statl-st_ctime_sec = st-st_ctime;
- statl-st_ctime_nsec = st-st_ctim.tv_nsec;
+ statl-st_mode = st-st_mode;
+ statl-st_nlink = st-st_nlink;
+ statl-st_uid = st-st_uid;
+ statl-st_gid = st-st_gid;
+ statl-st_rdev = st-st_rdev;
+ statl-st_size = st-st_size;
+ statl-st_blksize = st-st_blksize;
+ statl-st_blocks= st-st_blocks;
+ statl-st_atime_sec = st-st_atime;
+ statl-st_atime_nsec= st-st_atim.tv_nsec;
+ statl-st_mtime_sec = st-st_mtime;
+ statl-st_mtime_nsec= st-st_mtim.tv_nsec;
+ statl-st_ctime_sec = st-st_ctime;
+ statl-st_ctime_nsec= st-st_ctim.tv_nsec;
/* Currently we only support BASIC fields in stat */
- statl-st_result_mask = P9_STATS_BASIC;
+ statl-st_result_mask = P9_STATS_BASIC;
stat2qid(st, statl-qid);
}
@@ -692,7 +692,7 @@ err_out:
}
static void virtio_p9_remove(struct p9_dev *p9dev,
- struct p9_pdu *pdu, u32 *outlen)
+struct p9_pdu *pdu, u32 *outlen)
{
int ret;
u32 fid_val;
@@ -714,7 +714,7 @@ err_out:
}
static void virtio_p9_rename(struct p9_dev *p9dev,
- struct p9_pdu *pdu, u32 *outlen)
+struct p9_pdu *pdu, u32 *outlen)
{
int ret;
u32 fid_val, new_fid_val;
@@ -1121,12 +1121,10 @@ static struct p9_pdu *virtio_p9_pdu_init(struct kvm
*kvm, struct virt_queue *vq)
return NULL;
/* skip the pdu header p9_msg */
- pdu-read_offset = VIRTIO_9P_HDR_LEN;
- pdu-write_offset = VIRTIO_9P_HDR_LEN;
- pdu-queue_head = virt_queue__get_inout_iov(kvm, vq, pdu-in_iov,
-pdu-out_iov,
-pdu-in_iov_cnt,
-pdu-out_iov_cnt);
+ pdu-read_offset= VIRTIO_9P_HDR_LEN;
+ pdu-write_offset = VIRTIO_9P_HDR_LEN;
+ pdu-queue_head = virt_queue__get_inout_iov(kvm, vq,
pdu-in_iov,
+ pdu-out_iov, pdu-in_iov_cnt,
pdu-out_iov_cnt);
return pdu;
}
@@ -1215,16 +1213,16 @@ static int init_vq(struct kvm *kvm, void *dev, u32 vq,
u32 pfn)
compat__remove_message(compat_id);
- queue = p9dev-vqs[vq];
- queue-pfn = pfn;
- p = guest_pfn_to_host(kvm, queue-pfn);
- job = p9dev-jobs[vq];
+ queue = p9dev-vqs[vq];
+ queue-pfn = pfn;
+ p = guest_pfn_to_host(kvm, queue-pfn);
+ job = p9dev-jobs[vq];
vring_init(queue-vring, VIRTQUEUE_NUM, p, VIRTIO_PCI_VRING_ALIGN);
- *job= (struct p9_dev_job) {
- .vq = queue,
- .p9dev = p9dev,
+ *job= (struct p9_dev_job) {
+ .vq = queue,
+ .p9dev = p9dev,
};
thread_pool__init_job(job-job_id, kvm, virtio_p9_do_io, job);
--
1.7.10.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
[PATCH 2/8] kvm tools: Code cleanup for virtio/balloon.c
Signed-off-by: Asias He asias.he...@gmail.com --- tools/kvm/virtio/balloon.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/kvm/virtio/balloon.c b/tools/kvm/virtio/balloon.c index 45bd8d3..9f1d9bd 100644 --- a/tools/kvm/virtio/balloon.c +++ b/tools/kvm/virtio/balloon.c @@ -209,9 +209,9 @@ static int init_vq(struct kvm *kvm, void *dev, u32 vq, u32 pfn) compat__remove_message(compat_id); - queue = bdev-vqs[vq]; - queue-pfn = pfn; - p = guest_pfn_to_host(kvm, queue-pfn); + queue = bdev-vqs[vq]; + queue-pfn = pfn; + p = guest_pfn_to_host(kvm, queue-pfn); thread_pool__init_job(bdev-jobs[vq], kvm, virtio_bln_do_io, queue); vring_init(queue-vring, VIRTIO_BLN_QUEUE_SIZE, p, VIRTIO_PCI_VRING_ALIGN); -- 1.7.10.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
[PATCH 3/8] kvm tools: Code cleanup for virtio/blk.c
Signed-off-by: Asias He asias.he...@gmail.com
---
tools/kvm/virtio/blk.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/tools/kvm/virtio/blk.c b/tools/kvm/virtio/blk.c
index da92094..9256646 100644
--- a/tools/kvm/virtio/blk.c
+++ b/tools/kvm/virtio/blk.c
@@ -90,20 +90,21 @@ static void virtio_blk_do_io_request(struct kvm *kvm,
struct blk_dev_req *req)
switch (req_hdr-type) {
case VIRTIO_BLK_T_IN:
- block_cnt = disk_image__read(bdev-disk, req_hdr-sector,
iov + 1,
- in + out - 2, req);
+ block_cnt = disk_image__read(bdev-disk, req_hdr-sector,
+ iov + 1, in + out - 2, req);
break;
case VIRTIO_BLK_T_OUT:
- block_cnt = disk_image__write(bdev-disk,
req_hdr-sector, iov + 1,
- in + out - 2, req);
+ block_cnt = disk_image__write(bdev-disk, req_hdr-sector,
+ iov + 1, in + out - 2, req);
break;
case VIRTIO_BLK_T_FLUSH:
- block_cnt = disk_image__flush(bdev-disk);
+ block_cnt = disk_image__flush(bdev-disk);
virtio_blk_complete(req, block_cnt);
break;
case VIRTIO_BLK_T_GET_ID:
- block_cnt = VIRTIO_BLK_ID_BYTES;
- disk_image__get_serial(bdev-disk, (iov + 1)-iov_base,
block_cnt);
+ block_cnt = VIRTIO_BLK_ID_BYTES;
+ disk_image__get_serial(bdev-disk,
+ (iov + 1)-iov_base, block_cnt);
virtio_blk_complete(req, block_cnt);
break;
default:
@@ -121,7 +122,8 @@ static void virtio_blk_do_io(struct kvm *kvm, struct
virt_queue *vq, struct blk_
while (virt_queue__available(vq)) {
head= virt_queue__pop(vq);
req = bdev-reqs[head];
- req-head = virt_queue__get_head_iov(vq, req-iov,
req-out, req-in, head, kvm);
+ req-head = virt_queue__get_head_iov(vq, req-iov,
req-out,
+ req-in, head, kvm);
req-vq = vq;
virtio_blk_do_io_request(kvm, req);
@@ -165,9 +167,9 @@ static int init_vq(struct kvm *kvm, void *dev, u32 vq, u32
pfn)
compat__remove_message(compat_id);
- queue = bdev-vqs[vq];
- queue-pfn = pfn;
- p = guest_pfn_to_host(kvm, queue-pfn);
+ queue = bdev-vqs[vq];
+ queue-pfn = pfn;
+ p = guest_pfn_to_host(kvm, queue-pfn);
vring_init(queue-vring, VIRTIO_BLK_QUEUE_SIZE, p,
VIRTIO_PCI_VRING_ALIGN);
@@ -241,8 +243,8 @@ static int virtio_blk__init_one(struct kvm *kvm, struct
disk_image *disk)
list_add_tail(bdev-list, bdevs);
for (i = 0; i ARRAY_SIZE(bdev-reqs); i++) {
- bdev-reqs[i].bdev = bdev;
- bdev-reqs[i].kvm = kvm;
+ bdev-reqs[i].bdev = bdev;
+ bdev-reqs[i].kvm = kvm;
}
disk_image__set_callback(bdev-disk, virtio_blk_complete);
--
1.7.10.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
[PATCH 4/8] kvm tools: Code cleanup for virtio/console.c
Signed-off-by: Asias He asias.he...@gmail.com --- tools/kvm/virtio/console.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/kvm/virtio/console.c b/tools/kvm/virtio/console.c index 173c312..42472eb 100644 --- a/tools/kvm/virtio/console.c +++ b/tools/kvm/virtio/console.c @@ -138,9 +138,9 @@ static int init_vq(struct kvm *kvm, void *dev, u32 vq, u32 pfn) compat__remove_message(compat_id); - queue = cdev.vqs[vq]; - queue-pfn = pfn; - p = guest_pfn_to_host(kvm, queue-pfn); + queue = cdev.vqs[vq]; + queue-pfn = pfn; + p = guest_pfn_to_host(kvm, queue-pfn); vring_init(queue-vring, VIRTIO_CONSOLE_QUEUE_SIZE, p, VIRTIO_PCI_VRING_ALIGN); -- 1.7.10.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
[PATCH 5/8] kvm tools: Code cleanup for virtio/net.c
Signed-off-by: Asias He asias.he...@gmail.com
---
tools/kvm/virtio/net.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/kvm/virtio/net.c b/tools/kvm/virtio/net.c
index 35e51aa..50bef74 100644
--- a/tools/kvm/virtio/net.c
+++ b/tools/kvm/virtio/net.c
@@ -81,8 +81,8 @@ static void *virtio_net_rx_thread(void *p)
u16 head;
int len;
- kvm = ndev-kvm;
- vq = ndev-vqs[VIRTIO_NET_RX_QUEUE];
+ kvm = ndev-kvm;
+ vq = ndev-vqs[VIRTIO_NET_RX_QUEUE];
while (1) {
mutex_lock(ndev-io_rx_lock);
@@ -117,8 +117,8 @@ static void *virtio_net_tx_thread(void *p)
u16 head;
int len;
- kvm = ndev-kvm;
- vq = ndev-vqs[VIRTIO_NET_TX_QUEUE];
+ kvm = ndev-kvm;
+ vq = ndev-vqs[VIRTIO_NET_TX_QUEUE];
while (1) {
mutex_lock(ndev-io_tx_lock);
--
1.7.10.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
[PATCH 6/8] kvm tools: Code cleanup for disk/core.c
Signed-off-by: Asias He asias.he...@gmail.com
---
tools/kvm/disk/core.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/tools/kvm/disk/core.c b/tools/kvm/disk/core.c
index 58a5877..2b482c6 100644
--- a/tools/kvm/disk/core.c
+++ b/tools/kvm/disk/core.c
@@ -29,7 +29,9 @@ static void *disk_image__thread(void *param)
}
#endif
-struct disk_image *disk_image__new(int fd, u64 size, struct
disk_image_operations *ops, int use_mmap)
+struct disk_image *disk_image__new(int fd, u64 size,
+ struct disk_image_operations *ops,
+ int use_mmap)
{
struct disk_image *disk;
int r;
@@ -109,7 +111,8 @@ struct disk_image *disk_image__open(const char *filename,
bool readonly)
return ERR_PTR(-ENOSYS);
}
-struct disk_image **disk_image__open_all(const char **filenames, bool
*readonly, int count)
+struct disk_image **disk_image__open_all(const char **filenames,
+bool *readonly, int count)
{
struct disk_image **disks;
int i;
@@ -185,8 +188,8 @@ int disk_image__close_all(struct disk_image **disks, int
count)
* Fill iov with disk data, starting from sector 'sector'.
* Return amount of bytes read.
*/
-ssize_t disk_image__read(struct disk_image *disk, u64 sector, const struct
iovec *iov,
- int iovcount, void *param)
+ssize_t disk_image__read(struct disk_image *disk, u64 sector,
+const struct iovec *iov, int iovcount, void *param)
{
ssize_t total = 0;
@@ -199,8 +202,6 @@ ssize_t disk_image__read(struct disk_image *disk, u64
sector, const struct iovec
pr_info(disk_image__read error: total=%ld\n,
(long)total);
return total;
}
- } else {
- /* Do nothing */
}
if (!disk-async disk-disk_req_cb)
@@ -213,8 +214,8 @@ ssize_t disk_image__read(struct disk_image *disk, u64
sector, const struct iovec
* Write iov to disk, starting from sector 'sector'.
* Return amount of bytes written.
*/
-ssize_t disk_image__write(struct disk_image *disk, u64 sector, const struct
iovec *iov,
- int iovcount, void *param)
+ssize_t disk_image__write(struct disk_image *disk, u64 sector,
+ const struct iovec *iov, int iovcount, void *param)
{
ssize_t total = 0;
@@ -250,11 +251,13 @@ ssize_t disk_image__get_serial(struct disk_image *disk,
void *buffer, ssize_t *l
if (r)
return r;
- *len = snprintf(buffer, *len, %llu%llu%llu, (u64)st.st_dev,
(u64)st.st_rdev, (u64)st.st_ino);
+ *len = snprintf(buffer, *len, %llu%llu%llu,
+ (u64)st.st_dev, (u64)st.st_rdev, (u64)st.st_ino);
return *len;
}
-void disk_image__set_callback(struct disk_image *disk, void
(*disk_req_cb)(void *param, long len))
+void disk_image__set_callback(struct disk_image *disk,
+ void (*disk_req_cb)(void *param, long len))
{
disk-disk_req_cb = disk_req_cb;
}
--
1.7.10.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
[PATCH 7/8] kvm tools: Code cleanup for disk/qcow.c
Signed-off-by: Asias He asias.he...@gmail.com
---
tools/kvm/disk/qcow.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/kvm/disk/qcow.c b/tools/kvm/disk/qcow.c
index b3221c4..ee2992e 100644
--- a/tools/kvm/disk/qcow.c
+++ b/tools/kvm/disk/qcow.c
@@ -259,10 +259,10 @@ static int qcow_decompress_buffer(u8 *out_buf, int
out_buf_size,
memset(strm, 0, sizeof(*strm));
- strm-next_in = (u8 *)buf;
- strm-avail_in = buf_size;
- strm-next_out = out_buf;
- strm-avail_out = out_buf_size;
+ strm-next_in = (u8 *)buf;
+ strm-avail_in = buf_size;
+ strm-next_out = out_buf;
+ strm-avail_out = out_buf_size;
ret = inflateInit2(strm, -12);
if (ret != Z_OK)
@@ -330,9 +330,9 @@ static ssize_t qcow1_read_cluster(struct qcow *q, u64
offset,
clust_start = be64_to_cpu(l2t-table[l2_idx]);
if (clust_start QCOW1_OFLAG_COMPRESSED) {
- coffset = clust_start q-cluster_offset_mask;
- csize = clust_start (63 - q-header-cluster_bits);
- csize = (q-cluster_size - 1);
+ coffset = clust_start q-cluster_offset_mask;
+ csize = clust_start (63 - q-header-cluster_bits);
+ csize = (q-cluster_size - 1);
if (pread_in_full(q-fd, q-cluster_data, csize,
coffset) 0)
@@ -1223,7 +1223,7 @@ static int qcow_read_l1_table(struct qcow *q)
struct qcow_header *header = q-header;
struct qcow_l1_table *table = q-table;
- table-table_size = header-l1_size;
+ table-table_size = header-l1_size;
table-l1_table = calloc(table-table_size, sizeof(u64));
if (!table-l1_table)
--
1.7.10.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
[PATCH 8/8] kvm tools: Code cleanup for disk/raw.c
Signed-off-by: Asias He asias.he...@gmail.com
---
tools/kvm/disk/raw.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kvm/disk/raw.c b/tools/kvm/disk/raw.c
index 42ca9f1..93b2b4e 100644
--- a/tools/kvm/disk/raw.c
+++ b/tools/kvm/disk/raw.c
@@ -99,7 +99,7 @@ static struct disk_image_operations raw_image_regular_ops = {
struct disk_image_operations ro_ops = {
.read = raw_image__read_mmap,
.write = raw_image__write_mmap,
- .close = raw_image__close,
+ .close = raw_image__close,
};
struct disk_image_operations ro_ops_nowrite = {
--
1.7.10.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: do not iterate over all VMs in mmu_shrink()
On 06/04/2012 02:53 PM, Gleb Natapov wrote: mmu_shrink() needlessly iterates over all VMs even though it will not attempt to free mmu pages from more than one on them. Fix that and also check used mmu pages count outside of VM lock to skip inactive VMs faster. Applied, thanks. -- 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 v2] Fix migration of real mode guests from host with unrestricted guest to a host without it.
On 05/31/2012 02:49 PM, Orit Wasserman wrote: For example migration between Westmere and Nehelem hosts. The code that fixes the segments for real mode guest was moved from enter_rmode to vmx_set_segments. enter_rmode calls vmx_set_segments for each segment. Applied, thanks. -- 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: AMD KVM Pci Passthrough reports device busy
On Tue, 2012-06-05 at 17:17 +0200, Andreas Hartmann wrote: On Tue, 05 Jun 2012 08:27:05 -0600 Alex Williamson alex.william...@redhat.com wrote: On Tue, 2012-06-05 at 12:39 +0200, Andreas Hartmann wrote: Hello Alex, thanks for your efforts! Maybe, you already know that I'm suffering the same problem :-( with a GA-990XA-UD3 (990X chipset). My system is a GA-990FXA-UD3, so just a slightly different version of the chipset. On Mon, 04 Jun 2012 21:44:05 -0600 Alex Williamson alex.william...@redhat.com wrote: [...] I have a setup with an AMD 990FX system and a spare PVR-350 card that I installed to reproduce. The sad answer is that it's nearly impossible to assign PCI devices on these systems due to the aliasing of devices below the PCIe-to-PCI bridge (PCIe devices are much, much easier to assign). If you boot with amd_iommu_dump, you'll see some output like this: AMD-Vi: DEV_ALIAS_RANGEdevid: 05:00.0 flags: 00 devid_to: 00:14.4 AMD-Vi: DEV_RANGE_END devid: 05:1f.7 here: AMD-Vi: DEV_ALIAS_RANGE devid: 06:00.0 flags: 00 devid_to: 00:14.4 AMD-Vi: DEV_RANGE_END devid: 06:1f.7 This means according to your description, the following devices have to be unbound here, too (:06:07.0 is the device I want to passthrough): :00:14.0 - ../../../../devices/pci:00/:00:14.0 :00:14.1 - ../../../../devices/pci:00/:00:14.1 :00:14.2 - ../../../../devices/pci:00/:00:14.2 :00:14.3 - ../../../../devices/pci:00/:00:14.3 :00:14.4 - ../../../../devices/pci:00/:00:14.4 :00:14.5 - ../../../../devices/pci:00/:00:14.5 :06:07.0 - ../../../../devices/pci:00/:00:14.4/:06:07.0 Yep. These are the following additional devices: 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller (rev 42) 00:14.1 IDE interface: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 IDE Controller (rev 40) (prog-if 8a [Master SecP PriP]) 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40) 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 LPC host controller (rev 40) 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge (rev 40) (prog-if 01 [Subtractive decode]) 00:14.5 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI2 Controller (prog-if 10 [OHCI]) My system shows this for lspci -n -s 14. 00:14.0 0c05: 1002:4385 (rev 42) 00:14.2 0403: 1002:4383 (rev 40) 00:14.3 0601: 1002:439d (rev 40) 00:14.4 0604: 1002:4384 (rev 40) 00:14.5 0c03: 1002:4399 My system: 00:14.0 0c05: 1002:4385 (rev 42) 00:14.1 0101: 1002:439c (rev 40) 00:14.2 0403: 1002:4383 (rev 40) 00:14.3 0601: 1002:439d (rev 40) 00:14.4 0604: 1002:4384 (rev 40) 00:14.5 0c03: 1002:4399 You miss 00.14.1!? But the others are equal. Yeah, my system doesn't expose the IDE, *shrug* Can you confirm yours matches and fill in 14.1 so we have the vendor:device IDs for these. Yes. Thanks Among them is the sound device and the USB device - no good idea to disable them on a desktop. You can always blacklist drivers if the device is unique or unbind devices in an rc.local type script. I'm hoping that Joerg or someone else from AMD can tell us this devices does not allow internal peer-to-peer between functions. Then we can add it to the device specific ACS checks and you wouldn't need to worry about displacing all the other 14.x functions. This would be cool. Disabling 00:14.1 seems to be possible (rmmod pata_atiixp works), but I'm getting errors after rebooting the system (the filesystems haven't been cleanly unmounted during shutdown). Did you have a disk off that controller? My system doesn't expose function 1, but is the same otherwise. Filesystems on my ssd (Corsair Force GT) show the problem. Maybe the reason is another? Anyway, I would have tested it, but I'm getting a compile error while compiling qemu. It complains about missing pci/header.h while processing hw/vfio_pci.c:49:24. I can't find any pci/header.h. Where should it come from? It is from pciutils-devel for me. I'll see what I'm getting out of there and try to remove it. Meanwhile I found it :-). Thanks for your hint! Great. The downside is that VFIO is strict about multifunction devices supporting ACS to prevent peer-to-peer between domains, so will require all of the 14.x devices to be bound to pci-stub as well. On my system, this includes an smbus controller, audio device, lpc controller, and usb device. If AMD could confirm this device doesn't allow peer-to-peer between functions, we could relax this requirement a bit. Please
Re: AMD KVM Pci Passthrough reports device busy
Andreas Hartmann wrote:
[...]
I tried to run qemu-system-x86_64 but got this error on startup:
qemu-system-x86_64: -device
vfio-pci,host=06:07.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: failed to set
iommu for container: Operation not permitted
qemu-system-x86_64: -device
vfio-pci,host=06:07.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: failed to setup
container for group 9
qemu-system-x86_64: -device
vfio-pci,host=06:07.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: failed to get
group 9
**
ERROR:qom/object.c:389:object_delete: assertion failed: (obj-ref == 0)
I started qemu-system-x86_64 with this option among others
-device vfio-pci,host=06:07.0,id=hostdev0,bus=pci.0,addr=0x5
after all of the devices have been added to pci-stub but 06:07.0, which was
added to vfio-pci.
Could you please tell me, why the operation isn't permitted? I started
qemu-system-x86_64 as root.
I straced the call with strace and got the following error:
...
8048 open(/usr/local/share/qemu/pxe-virtio.rom, O_RDONLY) = 14
8048 lseek(14, 0, SEEK_END)= 60416
8048 lseek(14, 0, SEEK_SET)= 0
8048 read(14, U\252v\351\217\0z\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\177\0
\0\0\365\274\266\16..., 60416) = 60416
8048 close(14) = 0
8048 stat(/sys/bus/pci/devices/:06:07.0/, {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0
8048 readlink(/sys/bus/pci/devices/:06:07.0/iommu_group,
../../../../kernel/iommu_groups/9..., 4096) = 33
8048 open(/dev/vfio/9, O_RDWR) = 14
8048 ioctl(14, 0x3b67, 0x7fff237d5ac0) = 0
8048 open(/dev/vfio/vfio, O_RDWR)= 15
8048 ioctl(15, 0x3b64, 0xf)= 0
8048 ioctl(15, 0x3b65, 0x1)= 1
8048 ioctl(14, 0x3b68, 0x7fff237d5ad8) = 0
8048 ioctl(15, 0x3b66, 0x1)= -1 EPERM (Operation not permitted)
...
/dev/vfio # ls -l
total 0
crw-rw-rw- 1 root root 250, 1 Jun 5 17:42 9
crw-rw-rw- 1 root root 250, 0 Jun 5 17:41 vfio
Kind regards,
Andreas
--
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/2] Provide fast path for rep ins emulation if possible.
On 05/23/2012 05:08 PM, Gleb Natapov wrote:
rep ins emulation is going through emulator now. This is slow because
emulator knows how to write back only one datum at a time. This patch
provides fast path for the instruction in certain conditions. The
conditions are: DF flag is not set, destination memory is RAM and single
datum does not cross page boundary. If fast path code fails it falls
back to emulation.
+static int __kvm_fast_string_pio_in(struct kvm_vcpu *vcpu, int size,
+ unsigned short port, unsigned long addr,
+ int count)
+{
+ struct page *page;
+ gpa_t gpa;
+ char *kaddr;
+ int ret;
+
+ gpa = kvm_mmu_gva_to_gpa_write(vcpu, addr, NULL);
+
+ if (gpa == UNMAPPED_GVA ||
+ (gpa PAGE_MASK) == APIC_DEFAULT_PHYS_BASE)
+ return EMULATE_FAIL;
+
+ page = gfn_to_page(vcpu-kvm, gpa PAGE_SHIFT);
+ if (is_error_page(page)) {
+ kvm_release_page_clean(page);
+ return EMULATE_FAIL;
+ }
+
+ kaddr = kmap_atomic(page);
+ kaddr += offset_in_page(gpa);
+
+ ret = emulator_pio_in_emulated(vcpu-arch.emulate_ctxt, size, port,
+ kaddr, count);
+
+ kunmap_atomic(kaddr);
+ if (ret) {
+ kvm_register_write(vcpu, VCPU_REGS_RCX,
+ kvm_register_read(vcpu, VCPU_REGS_RCX) - count);
Sometimes we only modify the low 16 bits of %rcx.
+ kvm_register_write(vcpu, VCPU_REGS_RDI,
+ kvm_register_read(vcpu, VCPU_REGS_RDI) +
count*size);
Possibly, ditto.
+ kvm_release_page_dirty(page);
+ return EMULATE_DONE;
+ }
+ kvm_release_page_clean(page);
+ return EMULATE_DO_MMIO;
+}
+
+
+int kvm_fast_string_pio_in(struct kvm_vcpu *vcpu, int size,
+ unsigned short port, u8 addr_size)
This is actually the logarithm of addr_size, the variable name should
reflect it.
+{
+ unsigned long masks[] = {0x, 0x, ~0};
+ unsigned long rdi = kvm_register_read(vcpu, VCPU_REGS_RDI);
+ unsigned long linear_addr = rdi + get_segment_base(vcpu, VCPU_SREG_ES);
+ unsigned long rcx = kvm_register_read(vcpu, VCPU_REGS_RCX), count;
+ int r;
+
Missing es limit check - rep in can succeed for part of the page, fail
when the %rdi hits the limit.
+ if (rcx == 0) {
+ kvm_x86_ops-skip_emulated_instruction(vcpu);
+ return EMULATE_DONE;
+ }
+ if (kvm_get_rflags(vcpu) X86_EFLAGS_DF)
+ return EMULATE_FAIL;
+ if (addr_size 2)
+ return EMULATE_FAIL;
+
+ linear_addr = masks[addr_size];
Also need to mask %rcx.
+
+ count = (PAGE_SIZE - offset_in_page(linear_addr))/size;
+
+ if (count == 0) /* 'in' crosses page boundry */
+ return EMULATE_FAIL;
+
+ count = min(count, rcx);
+
+ r = __kvm_fast_string_pio_in(vcpu, size, port, linear_addr, count);
+
+ if (r != EMULATE_DO_MMIO)
+ return r;
+
+ vcpu-arch.fast_string_pio_ctxt.linear_addr = linear_addr;
+ vcpu-arch.complete_userspace_io = complete_fast_string_pio;
+ return EMULATE_DO_MMIO;
+}
+EXPORT_SYMBOL_GPL(kvm_fast_string_pio_in);
Perhaps a better way to do it is to move the code into the emulator,
which already handles all the checks and masks, and just avoid
x86_decode_insn()/x86_emulate_insn().
+
static void tsc_bad(void *info)
{
__this_cpu_write(cpu_tsc_khz, 0);
--
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
[PATCH 1/2] kvm tools: Introduce virtio_compat_add_message() helper
This patch introduces a helper virtio_compat_add_message() to simplify
adding compat message for virtio device.
Signed-off-by: Asias He asias.he...@gmail.com
---
tools/kvm/include/kvm/virtio.h |1 +
tools/kvm/virtio/9p.c |7 +--
tools/kvm/virtio/balloon.c |7 +--
tools/kvm/virtio/blk.c |7 +--
tools/kvm/virtio/console.c |7 +--
tools/kvm/virtio/core.c| 33 +
tools/kvm/virtio/net.c |7 +--
tools/kvm/virtio/rng.c |7 +--
8 files changed, 40 insertions(+), 36 deletions(-)
diff --git a/tools/kvm/include/kvm/virtio.h b/tools/kvm/include/kvm/virtio.h
index 68eff15..a957a5b 100644
--- a/tools/kvm/include/kvm/virtio.h
+++ b/tools/kvm/include/kvm/virtio.h
@@ -98,4 +98,5 @@ struct virtio_ops {
int virtio_init(struct kvm *kvm, void *dev, struct virtio_device *vdev,
struct virtio_ops *ops, enum virtio_trans trans,
int device_id, int subsys_id, int class);
+int virtio_compat_add_message(const char *device, const char *config);
#endif /* KVM__VIRTIO_H */
diff --git a/tools/kvm/virtio/9p.c b/tools/kvm/virtio/9p.c
index 4108e02..b388d66 100644
--- a/tools/kvm/virtio/9p.c
+++ b/tools/kvm/virtio/9p.c
@@ -1313,12 +1313,7 @@ int virtio_9p__register(struct kvm *kvm, const char
*root, const char *tag_name)
list_add(p9dev-list, devs);
if (compat_id != -1)
- compat_id = compat__add_message(virtio-9p device was not
detected,
- While you have requested a
virtio-9p device,
- the guest kernel did not
initialize it.\n
- Please make sure that the
guest kernel was
- compiled with
CONFIG_NET_9P_VIRTIO=y enabled
- in its .config);
+ compat_id = virtio_compat_add_message(virtio-9p,
CONFIG_NET_9P_VIRTIO);
return err;
diff --git a/tools/kvm/virtio/balloon.c b/tools/kvm/virtio/balloon.c
index 9f1d9bd..e442714 100644
--- a/tools/kvm/virtio/balloon.c
+++ b/tools/kvm/virtio/balloon.c
@@ -263,10 +263,5 @@ void virtio_bln__init(struct kvm *kvm)
VIRTIO_PCI, PCI_DEVICE_ID_VIRTIO_BLN, VIRTIO_ID_BALLOON,
PCI_CLASS_BLN);
if (compat_id != -1)
- compat_id = compat__add_message(virtio-balloon device was not
detected,
- While you have requested a
virtio-balloon device,
- the guest kernel did not
initialize it.\n
- Please make sure that the
guest kernel was
- compiled with
CONFIG_VIRTIO_BALLOON=y enabled
- in its .config);
+ compat_id = virtio_compat_add_message(virtio-balloon,
CONFIG_VIRTIO_BALLOON);
}
diff --git a/tools/kvm/virtio/blk.c b/tools/kvm/virtio/blk.c
index 9256646..55ce26f 100644
--- a/tools/kvm/virtio/blk.c
+++ b/tools/kvm/virtio/blk.c
@@ -250,12 +250,7 @@ static int virtio_blk__init_one(struct kvm *kvm, struct
disk_image *disk)
disk_image__set_callback(bdev-disk, virtio_blk_complete);
if (compat_id != -1)
- compat_id = compat__add_message(virtio-blk device was not
detected,
- While you have requested a
virtio-blk device,
- the guest kernel did not
initialize it.\n
- Please make sure that the
guest kernel was
- compiled with
CONFIG_VIRTIO_BLK=y enabled
- in its .config);
+ compat_id = virtio_compat_add_message(virtio-blk,
CONFIG_VIRTIO_BLK);
return 0;
}
diff --git a/tools/kvm/virtio/console.c b/tools/kvm/virtio/console.c
index 42472eb..3493905 100644
--- a/tools/kvm/virtio/console.c
+++ b/tools/kvm/virtio/console.c
@@ -189,10 +189,5 @@ void virtio_console__init(struct kvm *kvm)
virtio_init(kvm, cdev, cdev.vdev, con_dev_virtio_ops,
VIRTIO_PCI, PCI_DEVICE_ID_VIRTIO_CONSOLE,
VIRTIO_ID_CONSOLE, PCI_CLASS_CONSOLE);
if (compat_id != -1)
- compat_id = compat__add_message(virtio-console device was not
detected,
- While you have requested a
virtio-console device,
- the guest kernel did not
initialize it.\n
- Please make sure that the
guest kernel was
- compiled with
CONFIG_VIRTIO_CONSOLE=y enabled
- in its .config);
+
[PATCH 2/2] kvm tools: Fix compat message
compat_id is initialized to -1 for each type of device. We should add
compat message if the compat_id == -1 which means we haven't added
compat message for this type of device.
Signed-off-by: Asias He asias.he...@gmail.com
---
tools/kvm/virtio/9p.c |2 +-
tools/kvm/virtio/balloon.c |2 +-
tools/kvm/virtio/blk.c |2 +-
tools/kvm/virtio/console.c |2 +-
tools/kvm/virtio/net.c |2 +-
tools/kvm/virtio/rng.c |2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/kvm/virtio/9p.c b/tools/kvm/virtio/9p.c
index b388d66..b4341b9 100644
--- a/tools/kvm/virtio/9p.c
+++ b/tools/kvm/virtio/9p.c
@@ -1312,7 +1312,7 @@ int virtio_9p__register(struct kvm *kvm, const char
*root, const char *tag_name)
list_add(p9dev-list, devs);
- if (compat_id != -1)
+ if (compat_id == -1)
compat_id = virtio_compat_add_message(virtio-9p,
CONFIG_NET_9P_VIRTIO);
return err;
diff --git a/tools/kvm/virtio/balloon.c b/tools/kvm/virtio/balloon.c
index e442714..a838ff4 100644
--- a/tools/kvm/virtio/balloon.c
+++ b/tools/kvm/virtio/balloon.c
@@ -262,6 +262,6 @@ void virtio_bln__init(struct kvm *kvm)
virtio_init(kvm, bdev, bdev.vdev, bln_dev_virtio_ops,
VIRTIO_PCI, PCI_DEVICE_ID_VIRTIO_BLN, VIRTIO_ID_BALLOON,
PCI_CLASS_BLN);
- if (compat_id != -1)
+ if (compat_id == -1)
compat_id = virtio_compat_add_message(virtio-balloon,
CONFIG_VIRTIO_BALLOON);
}
diff --git a/tools/kvm/virtio/blk.c b/tools/kvm/virtio/blk.c
index 55ce26f..c7dfc81 100644
--- a/tools/kvm/virtio/blk.c
+++ b/tools/kvm/virtio/blk.c
@@ -249,7 +249,7 @@ static int virtio_blk__init_one(struct kvm *kvm, struct
disk_image *disk)
disk_image__set_callback(bdev-disk, virtio_blk_complete);
- if (compat_id != -1)
+ if (compat_id == -1)
compat_id = virtio_compat_add_message(virtio-blk,
CONFIG_VIRTIO_BLK);
return 0;
}
diff --git a/tools/kvm/virtio/console.c b/tools/kvm/virtio/console.c
index 3493905..4bb1365 100644
--- a/tools/kvm/virtio/console.c
+++ b/tools/kvm/virtio/console.c
@@ -188,6 +188,6 @@ void virtio_console__init(struct kvm *kvm)
{
virtio_init(kvm, cdev, cdev.vdev, con_dev_virtio_ops,
VIRTIO_PCI, PCI_DEVICE_ID_VIRTIO_CONSOLE,
VIRTIO_ID_CONSOLE, PCI_CLASS_CONSOLE);
- if (compat_id != -1)
+ if (compat_id == -1)
compat_id = virtio_compat_add_message(virtio-console,
CONFIG_VIRTIO_CONSOLE);
}
diff --git a/tools/kvm/virtio/net.c b/tools/kvm/virtio/net.c
index da44198..ae17eb5 100644
--- a/tools/kvm/virtio/net.c
+++ b/tools/kvm/virtio/net.c
@@ -547,6 +547,6 @@ void virtio_net__init(const struct virtio_net_params
*params)
else
virtio_net__io_thread_init(params-kvm, ndev);
- if (compat_id != -1)
+ if (compat_id == -1)
compat_id = virtio_compat_add_message(virtio-net,
CONFIG_VIRTIO_NET);
}
diff --git a/tools/kvm/virtio/rng.c b/tools/kvm/virtio/rng.c
index 202104c..5aa632d 100644
--- a/tools/kvm/virtio/rng.c
+++ b/tools/kvm/virtio/rng.c
@@ -170,7 +170,7 @@ int virtio_rng__init(struct kvm *kvm)
list_add_tail(rdev-list, rdevs);
- if (compat_id != -1)
+ if (compat_id == -1)
compat_id = virtio_compat_add_message(virtio-rng,
CONFIG_HW_RANDOM_VIRTIO);
return 0;
cleanup:
--
1.7.10.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: AMD KVM Pci Passthrough reports device busy
On Tue, 2012-06-05 at 17:58 +0200, Andreas Hartmann wrote:
Andreas Hartmann wrote:
[...]
I tried to run qemu-system-x86_64 but got this error on startup:
qemu-system-x86_64: -device
vfio-pci,host=06:07.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: failed to set
iommu for container: Operation not permitted
qemu-system-x86_64: -device
vfio-pci,host=06:07.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: failed to setup
container for group 9
qemu-system-x86_64: -device
vfio-pci,host=06:07.0,id=hostdev0,bus=pci.0,addr=0x5: vfio: failed to get
group 9
**
ERROR:qom/object.c:389:object_delete: assertion failed: (obj-ref == 0)
I started qemu-system-x86_64 with this option among others
-device vfio-pci,host=06:07.0,id=hostdev0,bus=pci.0,addr=0x5
after all of the devices have been added to pci-stub but 06:07.0, which was
added to vfio-pci.
Could you please tell me, why the operation isn't permitted? I started
qemu-system-x86_64 as root.
I straced the call with strace and got the following error:
...
8048 open(/usr/local/share/qemu/pxe-virtio.rom, O_RDONLY) = 14
8048 lseek(14, 0, SEEK_END)= 60416
8048 lseek(14, 0, SEEK_SET)= 0
8048 read(14, U\252v\351\217\0z\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\177\0
\0\0\365\274\266\16..., 60416) = 60416
8048 close(14) = 0
8048 stat(/sys/bus/pci/devices/:06:07.0/, {st_mode=S_IFDIR|0755,
st_size=0, ...}) = 0
8048 readlink(/sys/bus/pci/devices/:06:07.0/iommu_group,
../../../../kernel/iommu_groups/9..., 4096) = 33
8048 open(/dev/vfio/9, O_RDWR) = 14
8048 ioctl(14, 0x3b67, 0x7fff237d5ac0) = 0
8048 open(/dev/vfio/vfio, O_RDWR)= 15
8048 ioctl(15, 0x3b64, 0xf)= 0
8048 ioctl(15, 0x3b65, 0x1)= 1
8048 ioctl(14, 0x3b68, 0x7fff237d5ad8) = 0
8048 ioctl(15, 0x3b66, 0x1)= -1 EPERM (Operation not permitted)
...
Yep, I think the previous suggestion about reloading vfio_iommu_type1
with allow_unsafe_interrupts=1 will solve it. It has nothing to do with
file permissions, you're getting EPERM at the point where we set the
iommu type, which enables access to devices. By default we want an
iommu which protects against malicious MSI attacks, which requires
interrupt remapping on x86. Joerg has been working to add this for AMD
since the hardware supports it, but for now, the above options lets us
bypass the check. Thanks,
Alex
--
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 1/3 v2] kvm tools: Introduce virtio_compat_add_message() helper
This patch introduces a helper virtio_compat_add_message() to simplify
adding compat message for virtio device.
Signed-off-by: Asias He asias.he...@gmail.com
---
tools/kvm/include/kvm/virtio.h |1 +
tools/kvm/virtio/9p.c |7 +--
tools/kvm/virtio/balloon.c |7 +--
tools/kvm/virtio/blk.c |7 +--
tools/kvm/virtio/console.c |7 +--
tools/kvm/virtio/core.c| 33 +
tools/kvm/virtio/net.c |7 +--
tools/kvm/virtio/rng.c |7 +--
8 files changed, 40 insertions(+), 36 deletions(-)
diff --git a/tools/kvm/include/kvm/virtio.h b/tools/kvm/include/kvm/virtio.h
index 68eff15..a957a5b 100644
--- a/tools/kvm/include/kvm/virtio.h
+++ b/tools/kvm/include/kvm/virtio.h
@@ -98,4 +98,5 @@ struct virtio_ops {
int virtio_init(struct kvm *kvm, void *dev, struct virtio_device *vdev,
struct virtio_ops *ops, enum virtio_trans trans,
int device_id, int subsys_id, int class);
+int virtio_compat_add_message(const char *device, const char *config);
#endif /* KVM__VIRTIO_H */
diff --git a/tools/kvm/virtio/9p.c b/tools/kvm/virtio/9p.c
index 4108e02..b388d66 100644
--- a/tools/kvm/virtio/9p.c
+++ b/tools/kvm/virtio/9p.c
@@ -1313,12 +1313,7 @@ int virtio_9p__register(struct kvm *kvm, const char
*root, const char *tag_name)
list_add(p9dev-list, devs);
if (compat_id != -1)
- compat_id = compat__add_message(virtio-9p device was not
detected,
- While you have requested a
virtio-9p device,
- the guest kernel did not
initialize it.\n
- Please make sure that the
guest kernel was
- compiled with
CONFIG_NET_9P_VIRTIO=y enabled
- in its .config);
+ compat_id = virtio_compat_add_message(virtio-9p,
CONFIG_NET_9P_VIRTIO);
return err;
diff --git a/tools/kvm/virtio/balloon.c b/tools/kvm/virtio/balloon.c
index 9f1d9bd..e442714 100644
--- a/tools/kvm/virtio/balloon.c
+++ b/tools/kvm/virtio/balloon.c
@@ -263,10 +263,5 @@ void virtio_bln__init(struct kvm *kvm)
VIRTIO_PCI, PCI_DEVICE_ID_VIRTIO_BLN, VIRTIO_ID_BALLOON,
PCI_CLASS_BLN);
if (compat_id != -1)
- compat_id = compat__add_message(virtio-balloon device was not
detected,
- While you have requested a
virtio-balloon device,
- the guest kernel did not
initialize it.\n
- Please make sure that the
guest kernel was
- compiled with
CONFIG_VIRTIO_BALLOON=y enabled
- in its .config);
+ compat_id = virtio_compat_add_message(virtio-balloon,
CONFIG_VIRTIO_BALLOON);
}
diff --git a/tools/kvm/virtio/blk.c b/tools/kvm/virtio/blk.c
index 9256646..55ce26f 100644
--- a/tools/kvm/virtio/blk.c
+++ b/tools/kvm/virtio/blk.c
@@ -250,12 +250,7 @@ static int virtio_blk__init_one(struct kvm *kvm, struct
disk_image *disk)
disk_image__set_callback(bdev-disk, virtio_blk_complete);
if (compat_id != -1)
- compat_id = compat__add_message(virtio-blk device was not
detected,
- While you have requested a
virtio-blk device,
- the guest kernel did not
initialize it.\n
- Please make sure that the
guest kernel was
- compiled with
CONFIG_VIRTIO_BLK=y enabled
- in its .config);
+ compat_id = virtio_compat_add_message(virtio-blk,
CONFIG_VIRTIO_BLK);
return 0;
}
diff --git a/tools/kvm/virtio/console.c b/tools/kvm/virtio/console.c
index 42472eb..3493905 100644
--- a/tools/kvm/virtio/console.c
+++ b/tools/kvm/virtio/console.c
@@ -189,10 +189,5 @@ void virtio_console__init(struct kvm *kvm)
virtio_init(kvm, cdev, cdev.vdev, con_dev_virtio_ops,
VIRTIO_PCI, PCI_DEVICE_ID_VIRTIO_CONSOLE,
VIRTIO_ID_CONSOLE, PCI_CLASS_CONSOLE);
if (compat_id != -1)
- compat_id = compat__add_message(virtio-console device was not
detected,
- While you have requested a
virtio-console device,
- the guest kernel did not
initialize it.\n
- Please make sure that the
guest kernel was
- compiled with
CONFIG_VIRTIO_CONSOLE=y enabled
- in its .config);
+
[PATCH 2/3] kvm tools: Fix compat message
compat_id is initialized to -1 for each type of device. We should add
compat message if the compat_id == -1 which means we haven't added
compat message for this type of device.
Signed-off-by: Asias He asias.he...@gmail.com
---
tools/kvm/virtio/9p.c |2 +-
tools/kvm/virtio/balloon.c |2 +-
tools/kvm/virtio/blk.c |2 +-
tools/kvm/virtio/console.c |2 +-
tools/kvm/virtio/net.c |2 +-
tools/kvm/virtio/rng.c |2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/kvm/virtio/9p.c b/tools/kvm/virtio/9p.c
index b388d66..b4341b9 100644
--- a/tools/kvm/virtio/9p.c
+++ b/tools/kvm/virtio/9p.c
@@ -1312,7 +1312,7 @@ int virtio_9p__register(struct kvm *kvm, const char
*root, const char *tag_name)
list_add(p9dev-list, devs);
- if (compat_id != -1)
+ if (compat_id == -1)
compat_id = virtio_compat_add_message(virtio-9p,
CONFIG_NET_9P_VIRTIO);
return err;
diff --git a/tools/kvm/virtio/balloon.c b/tools/kvm/virtio/balloon.c
index e442714..a838ff4 100644
--- a/tools/kvm/virtio/balloon.c
+++ b/tools/kvm/virtio/balloon.c
@@ -262,6 +262,6 @@ void virtio_bln__init(struct kvm *kvm)
virtio_init(kvm, bdev, bdev.vdev, bln_dev_virtio_ops,
VIRTIO_PCI, PCI_DEVICE_ID_VIRTIO_BLN, VIRTIO_ID_BALLOON,
PCI_CLASS_BLN);
- if (compat_id != -1)
+ if (compat_id == -1)
compat_id = virtio_compat_add_message(virtio-balloon,
CONFIG_VIRTIO_BALLOON);
}
diff --git a/tools/kvm/virtio/blk.c b/tools/kvm/virtio/blk.c
index 55ce26f..c7dfc81 100644
--- a/tools/kvm/virtio/blk.c
+++ b/tools/kvm/virtio/blk.c
@@ -249,7 +249,7 @@ static int virtio_blk__init_one(struct kvm *kvm, struct
disk_image *disk)
disk_image__set_callback(bdev-disk, virtio_blk_complete);
- if (compat_id != -1)
+ if (compat_id == -1)
compat_id = virtio_compat_add_message(virtio-blk,
CONFIG_VIRTIO_BLK);
return 0;
}
diff --git a/tools/kvm/virtio/console.c b/tools/kvm/virtio/console.c
index 3493905..4bb1365 100644
--- a/tools/kvm/virtio/console.c
+++ b/tools/kvm/virtio/console.c
@@ -188,6 +188,6 @@ void virtio_console__init(struct kvm *kvm)
{
virtio_init(kvm, cdev, cdev.vdev, con_dev_virtio_ops,
VIRTIO_PCI, PCI_DEVICE_ID_VIRTIO_CONSOLE,
VIRTIO_ID_CONSOLE, PCI_CLASS_CONSOLE);
- if (compat_id != -1)
+ if (compat_id == -1)
compat_id = virtio_compat_add_message(virtio-console,
CONFIG_VIRTIO_CONSOLE);
}
diff --git a/tools/kvm/virtio/net.c b/tools/kvm/virtio/net.c
index da44198..ae17eb5 100644
--- a/tools/kvm/virtio/net.c
+++ b/tools/kvm/virtio/net.c
@@ -547,6 +547,6 @@ void virtio_net__init(const struct virtio_net_params
*params)
else
virtio_net__io_thread_init(params-kvm, ndev);
- if (compat_id != -1)
+ if (compat_id == -1)
compat_id = virtio_compat_add_message(virtio-net,
CONFIG_VIRTIO_NET);
}
diff --git a/tools/kvm/virtio/rng.c b/tools/kvm/virtio/rng.c
index 202104c..5aa632d 100644
--- a/tools/kvm/virtio/rng.c
+++ b/tools/kvm/virtio/rng.c
@@ -170,7 +170,7 @@ int virtio_rng__init(struct kvm *kvm)
list_add_tail(rdev-list, rdevs);
- if (compat_id != -1)
+ if (compat_id == -1)
compat_id = virtio_compat_add_message(virtio-rng,
CONFIG_HW_RANDOM_VIRTIO);
return 0;
cleanup:
--
1.7.10.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
[PATCH 3/3] kvm tools: Improve compat message format
- Before: - *** Compatibility Warning *** virtio-blk device was not detected While you have requested a virtio-blk device, the guest kernel did not initialize it. Please make sure that the guest kernel was compiled with CONFIG_VIRTIO_BLK=y enabled in its .config *** Compatibility Warning *** virtio-net device was not detected While you have requested a virtio-net device, the guest kernel did not initialize it. Please make sure that the guest kernel was compiled with CONFIG_VIRTIO_NET=y enabled in its .config # KVM session ended normally. - After: - # KVM compatibility warning. virtio-blk device was not detected. While you have requested a virtio-blk device, the guest kernel did not initialize it. Please make sure that the guest kernel was compiled with CONFIG_VIRTIO_BLK=y enabled in .config. # KVM compatibility warning. virtio-net device was not detected. While you have requested a virtio-net device, the guest kernel did not initialize it. Please make sure that the guest kernel was compiled with CONFIG_VIRTIO_NET=y enabled in .config. # KVM session ended normally. Signed-off-by: Asias He asias.he...@gmail.com --- tools/kvm/guest_compat.c |2 +- tools/kvm/virtio/core.c |6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/kvm/guest_compat.c b/tools/kvm/guest_compat.c index 43b9035..fd4704b 100644 --- a/tools/kvm/guest_compat.c +++ b/tools/kvm/guest_compat.c @@ -86,7 +86,7 @@ int compat__print_all_messages(void) msg = list_first_entry(messages, struct compat_message, list); - printf(\n\n*** Compatibility Warning ***\n\n\t%s\n\n%s\n, + printf(\n # KVM compatibility warning.\n\t%s\n\t%s\n, msg-title, msg-desc); list_del(msg-list); diff --git a/tools/kvm/virtio/core.c b/tools/kvm/virtio/core.c index 8e0f63b..2dfb828 100644 --- a/tools/kvm/virtio/core.c +++ b/tools/kvm/virtio/core.c @@ -217,11 +217,11 @@ int virtio_compat_add_message(const char *device, const char *config) return -ENOMEM; } - snprintf(title, len, %s device was not detected, device); + snprintf(title, len, %s device was not detected., device); snprintf(desc, len, While you have requested a %s device, the guest kernel did not initialize it.\n -Please make sure that the guest kernel was -compiled with %s=y enabled in its .config, +\tPlease make sure that the guest kernel was +compiled with %s=y enabled in .config., device, config); compat_id = compat__add_message(title, desc); -- 1.7.10.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: AMD KVM Pci Passthrough reports device busy
Alex Williamson wrote: [...] Yep, I think the previous suggestion about reloading vfio_iommu_type1 with allow_unsafe_interrupts=1 will solve it. Yes! Works now. Success! Works means: Device is seen in VM. I couldn't test it up to now, because I don't have any driver in the VM for this device. It has nothing to do with file permissions, you're getting EPERM at the point where we set the iommu type, which enables access to devices. By default we want an iommu which protects against malicious MSI attacks, which requires interrupt remapping on x86. Joerg has been working to add this for AMD since the hardware supports it, but for now, the above options lets us bypass the check. Thanks, Now, I have to check my problem with the filesystem first, which isn't cleanly unmounted. I suspect a few missing options for kernel compile. Next will be fglrx :-) for 3.4 Hmmm, is there a chance to get your extension isolated to get it compiled for 3.1, too? Thanks, kind regards, Andreas -- 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: Fix PCI header check on device assignment
On Tue, 2012-06-05 at 10:37 +0200, Jan Kiszka wrote:
The masking was wrong (must have been 0x7f), and there is no need to
re-read the value as pci_setup_device already does this for us.
The intent was to mask off the multifunction bit from header_type, but
the implementation is clearly wrong. hdr_type does both. Thanks
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43339
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Acked-by: Alex Williamson alex.william...@redhat.com
---
virt/kvm/assigned-dev.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/virt/kvm/assigned-dev.c b/virt/kvm/assigned-dev.c
index 01f572c..b1e091a 100644
--- a/virt/kvm/assigned-dev.c
+++ b/virt/kvm/assigned-dev.c
@@ -635,7 +635,6 @@ static int kvm_vm_ioctl_assign_device(struct kvm *kvm,
int r = 0, idx;
struct kvm_assigned_dev_kernel *match;
struct pci_dev *dev;
- u8 header_type;
if (!(assigned_dev-flags KVM_DEV_ASSIGN_ENABLE_IOMMU))
return -EINVAL;
@@ -668,8 +667,7 @@ static int kvm_vm_ioctl_assign_device(struct kvm *kvm,
}
/* Don't allow bridges to be assigned */
- pci_read_config_byte(dev, PCI_HEADER_TYPE, header_type);
- if ((header_type PCI_HEADER_TYPE) != PCI_HEADER_TYPE_NORMAL) {
+ if (dev-hdr_type != PCI_HEADER_TYPE_NORMAL) {
r = -EPERM;
goto out_put;
}
--
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/2] Provide fast path for rep ins emulation if possible.
On Tue, Jun 05, 2012 at 07:07:39PM +0300, Avi Kivity wrote: + + count = (PAGE_SIZE - offset_in_page(linear_addr))/size; + + if (count == 0) /* 'in' crosses page boundry */ + return EMULATE_FAIL; + + count = min(count, rcx); + + r = __kvm_fast_string_pio_in(vcpu, size, port, linear_addr, count); + + if (r != EMULATE_DO_MMIO) + return r; + + vcpu-arch.fast_string_pio_ctxt.linear_addr = linear_addr; + vcpu-arch.complete_userspace_io = complete_fast_string_pio; + return EMULATE_DO_MMIO; +} +EXPORT_SYMBOL_GPL(kvm_fast_string_pio_in); Perhaps a better way to do it is to move the code into the emulator, which already handles all the checks and masks, and just avoid x86_decode_insn()/x86_emulate_insn(). I do not see how it would be better. Emulator works on different data structures that should be prepared and the only functions that we can reuse (as far as I see) are register_address_increment() and ad_mask() anyway. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Provide fast path for rep ins emulation if possible.
On 24.05.2012, at 12:54, Roedel, Joerg wrote: On Thu, May 24, 2012 at 01:36:51PM +0300, Avi Kivity wrote: On 05/24/2012 01:34 PM, Roedel, Joerg wrote: On Wed, May 23, 2012 at 05:49:31PM +0300, Avi Kivity wrote: On 05/23/2012 05:40 PM, Avi Kivity wrote: On 05/23/2012 05:08 PM, Gleb Natapov wrote: If decode assists are not available, we still need to emulate, see 15.33.5. Joerg, the 2010 version of the manual says that the effective segment (10:12) is only available with decode assists. The 2012 version says it's unconditional. What's correct? It is still conditional and only available with decode-assists. I will talk to the APM authors to clarify this in the documentation. Thanks. As it happens it doesn't matter for INS emulation, only OUTS, unless other bits in that word also depend on decode assists. Doesn't look like it. All other bits EXITINFO1 bits for the IOIO intercept are documented from the very ancient beginnings of SVM. So the segment number is the only addition. I do remember some bits missing in early implementations though. Don't ask me what, I just remember that when looking at intercept logs back in the day, some bits were not set even though they were documented as such - and those were pretty crucial bits, which is why we go through the emulator usually. Alex -- 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/2] Provide fast path for rep ins emulation if possible.
On Tue, Jun 05, 2012 at 07:27:40PM +0200, Alexander Graf wrote: On 24.05.2012, at 12:54, Roedel, Joerg wrote: On Thu, May 24, 2012 at 01:36:51PM +0300, Avi Kivity wrote: On 05/24/2012 01:34 PM, Roedel, Joerg wrote: On Wed, May 23, 2012 at 05:49:31PM +0300, Avi Kivity wrote: On 05/23/2012 05:40 PM, Avi Kivity wrote: On 05/23/2012 05:08 PM, Gleb Natapov wrote: If decode assists are not available, we still need to emulate, see 15.33.5. Joerg, the 2010 version of the manual says that the effective segment (10:12) is only available with decode assists. The 2012 version says it's unconditional. What's correct? It is still conditional and only available with decode-assists. I will talk to the APM authors to clarify this in the documentation. Thanks. As it happens it doesn't matter for INS emulation, only OUTS, unless other bits in that word also depend on decode assists. Doesn't look like it. All other bits EXITINFO1 bits for the IOIO intercept are documented from the very ancient beginnings of SVM. So the segment number is the only addition. I do remember some bits missing in early implementations though. Don't ask me what, I just remember that when looking at intercept logs back in the day, some bits were not set even though they were documented as such - and those were pretty crucial bits, which is why we go through the emulator usually. I know exactly why code goes through the emulation because I made it do so :) And the reason was because the previous code didn't handle anything except string pio to memory with address increment. i.e the case this patch turns to fast path. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Provide fast path for rep ins emulation if possible.
On 05.06.2012, at 19:36, Gleb Natapov wrote: On Tue, Jun 05, 2012 at 07:27:40PM +0200, Alexander Graf wrote: On 24.05.2012, at 12:54, Roedel, Joerg wrote: On Thu, May 24, 2012 at 01:36:51PM +0300, Avi Kivity wrote: On 05/24/2012 01:34 PM, Roedel, Joerg wrote: On Wed, May 23, 2012 at 05:49:31PM +0300, Avi Kivity wrote: On 05/23/2012 05:40 PM, Avi Kivity wrote: On 05/23/2012 05:08 PM, Gleb Natapov wrote: If decode assists are not available, we still need to emulate, see 15.33.5. Joerg, the 2010 version of the manual says that the effective segment (10:12) is only available with decode assists. The 2012 version says it's unconditional. What's correct? It is still conditional and only available with decode-assists. I will talk to the APM authors to clarify this in the documentation. Thanks. As it happens it doesn't matter for INS emulation, only OUTS, unless other bits in that word also depend on decode assists. Doesn't look like it. All other bits EXITINFO1 bits for the IOIO intercept are documented from the very ancient beginnings of SVM. So the segment number is the only addition. I do remember some bits missing in early implementations though. Don't ask me what, I just remember that when looking at intercept logs back in the day, some bits were not set even though they were documented as such - and those were pretty crucial bits, which is why we go through the emulator usually. I know exactly why code goes through the emulation because I made it do so :) And the reason was because the previous code didn't handle anything except string pio to memory with address increment. i.e the case this patch turns to fast path. No, what I'm saying is that the hardware omitted some fields even though they were provided in the spec. IIRC it was the size field, but I could be wrong. Please take an old (phenom / barcelona is old enough) machine and create some traces to make 100% sure that all fields you're trying to read out are actually provided. Alex -- 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/2] Provide fast path for rep ins emulation if possible.
On Tue, Jun 05, 2012 at 07:41:17PM +0200, Alexander Graf wrote: On 05.06.2012, at 19:36, Gleb Natapov wrote: On Tue, Jun 05, 2012 at 07:27:40PM +0200, Alexander Graf wrote: On 24.05.2012, at 12:54, Roedel, Joerg wrote: On Thu, May 24, 2012 at 01:36:51PM +0300, Avi Kivity wrote: On 05/24/2012 01:34 PM, Roedel, Joerg wrote: On Wed, May 23, 2012 at 05:49:31PM +0300, Avi Kivity wrote: On 05/23/2012 05:40 PM, Avi Kivity wrote: On 05/23/2012 05:08 PM, Gleb Natapov wrote: If decode assists are not available, we still need to emulate, see 15.33.5. Joerg, the 2010 version of the manual says that the effective segment (10:12) is only available with decode assists. The 2012 version says it's unconditional. What's correct? It is still conditional and only available with decode-assists. I will talk to the APM authors to clarify this in the documentation. Thanks. As it happens it doesn't matter for INS emulation, only OUTS, unless other bits in that word also depend on decode assists. Doesn't look like it. All other bits EXITINFO1 bits for the IOIO intercept are documented from the very ancient beginnings of SVM. So the segment number is the only addition. I do remember some bits missing in early implementations though. Don't ask me what, I just remember that when looking at intercept logs back in the day, some bits were not set even though they were documented as such - and those were pretty crucial bits, which is why we go through the emulator usually. I know exactly why code goes through the emulation because I made it do so :) And the reason was because the previous code didn't handle anything except string pio to memory with address increment. i.e the case this patch turns to fast path. No, what I'm saying is that the hardware omitted some fields even though they were provided in the spec. IIRC it was the size field, but I could be wrong. Please take an old (phenom / barcelona is old enough) machine and create some traces to make 100% sure that all fields you're trying to read out are actually provided. May be you are right about missing fields, but I am definitely know that this is not the reason string PIO goes through the emulator. Are you sure missing fields where on AMD? Intel did miss some crucial info in early versions. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Provide fast path for rep ins emulation if possible.
On Tue, Jun 05, 2012 at 07:41:17PM +0200, Alexander Graf wrote: IIRC it was the size field, but I could be wrong. Please take an old (phenom / barcelona is old enough) machine and create some traces to make 100% sure that all fields you're trying to read out are actually provided. Joerg do you know about an errata of such kind? -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Provide fast path for rep ins emulation if possible.
On Tue, Jun 05, 2012 at 08:50:16PM +0300, Gleb Natapov wrote: No, what I'm saying is that the hardware omitted some fields even though they were provided in the spec. IIRC it was the size field, but I could be wrong. Please take an old (phenom / barcelona is old enough) machine and create some traces to make 100% sure that all fields you're trying to read out are actually provided. May be you are right about missing fields, but I am definitely know that this is not the reason string PIO goes through the emulator. Are you sure missing fields where on AMD? Intel did miss some crucial info in early versions. I double checked and while emulation of string PIO was outside of emulator the decode went through emulator. The size field should be OK though since it is used for regular PIO emulation, so may be the problem was with address size or with effective data segment. If later then this is well known and does not influence this patch. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: at arch/x86/kernel/kvmclock.c:127
Hi all, I observed the following warning during testing of 3.5-rc1, involving some intensive and random CPU online state toggling through sysfs. It only shows up about 1 out of 500 times. Also, there was no KVM guest running on the system. [ cut here ] WARNING: at arch/x86/kernel/kvmclock.c:127 kvm_check_and_clear_guest_paused+0x52/0x60() Hardware name: Dinar Modules linked in: nfs lockd fscache auth_rpcgss nfs_acl sunrpc ipv6 ext4 jbd2 dm_mod powernow_k8 freq_table mperf kvm_amd kvm crc32c_intel ghash_clmulni_intel aesni_intel cryptd aes_x86_64 aes_generic microcode serio_raw pcspkr k10temp amd64_edac_mod edac_core edac_mce_amd i2c_piix4 sg bnx2 ext3 jbd mbcache sr_mod cdrom sd_mod crc_t10dif ata_generic pata_acpi pata_atiixp ahci libahci usb_storage radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan] Pid: 3593, comm: py_topology Not tainted 3.5.0-rc1+ #1 Call Trace: [8104fd7f] warn_slowpath_common+0x7f/0xc0 [8104fdda] warn_slowpath_null+0x1a/0x20 [8103f252] kvm_check_and_clear_guest_paused+0x52/0x60 [810d29f7] watchdog_timer_fn+0x97/0x1b0 [81077743] __run_hrtimer+0x83/0x1d0 [810d2960] ? touch_softlockup_watchdog_sync+0x40/0x40 [81077b26] hrtimer_interrupt+0x106/0x240 [81077d98] migrate_hrtimers+0x138/0x1a0 [8150eb76] hrtimer_cpu_notify+0xe4/0xeb [8151a655] notifier_call_chain+0x55/0x80 [8107961e] __raw_notifier_call_chain+0xe/0x10 [81052e50] __cpu_notify+0x20/0x40 [81052e85] cpu_notify_nofail+0x15/0x30 [814fc6bd] _cpu_down+0x12d/0x270 [814fc836] cpu_down+0x36/0x50 [814feeb4] store_online+0x74/0xd0 [8133e8a0] dev_attr_store+0x20/0x30 [811e0d5f] sysfs_write_file+0xef/0x170 [81171708] vfs_write+0xc8/0x190 [811718d1] sys_write+0x51/0x90 [8151eba9] system_call_fastpath+0x16/0x1b ---[ end trace 574db9e069f4f35e ]--- This is a regression introduced by the following commit: commit 3b5d56b9317fa7b5407dff1aa7b115bf6cdbd494 Author: Eric B Munson emun...@mgebm.net Date: Sat Mar 10 14:37:26 2012 -0500 kvmclock: Add functions to check if the host has stopped the vm When a host stops or suspends a VM it will set a flag to show this. The watchdog will use these functions to determine if a softlockup is real, or the result of a suspended VM. Signed-off-by: Eric B Munson emun...@mgebm.net asm-generic changes Acked-by: Arnd Bergmann a...@arndb.de Signed-off-by: Marcelo Tosatti mtosa...@redhat.com Signed-off-by: Avi Kivity a...@redhat.com -- Regards, Frank Arnold Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach GM: Alberto Bozzo Reg: Dornach, Landkreis Muenchen HRB Nr. 43632 WEEE Registernr: 129 19551 -- 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: [RFC][PATCH] Add support for the GUEST_SMBASE VMCS field for Intel VT-x.
On Tue, Jun 05, 2012 at 04:09:30PM +0300, Avi Kivity wrote: On 06/05/2012 02:59 PM, Matthias Lange wrote: Do you mean the ABI defined in the Intel Software Developer's manual 3B? Or is vmcs12 only an ABI internal to the kvm module? The latter. We want to be able to live migrate a guest with nested guests, and if the format of vmcs12 changes, the migration will break. I'm trying to understand how the migration is implemented in kvm. Can you point me to some sort of documentation or pieces of code where I can start digging through the mechanism? Thanks, Matthias. -- Dipl.-Inf. Matthias Lange mla...@sec.t-labs.tu-berlin.de Security in Telecommunications TU Berlin / Telekom Innovation Laboratories Ernst-Reuter-Platz 7, 10587 Berlin Phone: +49 - 30 - 8353 58 553 Mobile: +49 - 160 - 587 28 07 Web: http://www.t-labs.tu-berlin.de/sect -- 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
[Bug 43339] Wrong Pci-Bridge Header Type check.
https://bugzilla.kernel.org/show_bug.cgi?id=43339 Alex Williamson alex.william...@redhat.com changed: What|Removed |Added CC||alex.william...@redhat.com --- Comment #1 from Alex Williamson alex.william...@redhat.com 2012-06-05 18:33:46 --- (In reply to comment #0) So, 1 0xE == 0 thus KVM assigns pci-bridge device to VM successfully. Have you found this to be true in practice? The test here is clearly wrong, but immediately after this we test pci-sysfs resource permissions. We only test standard device resources, as we're not expecting a bridge to get through, but I believe those should all be zero for a bridge, which will result in denying assignment of the device because it has no resources. If you have a pci-bridge that actually makes it through that test, please include lspci -vvv for it here. Thanks -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- 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: AMD KVM Pci Passthrough reports device busy
On Tue, 2012-06-05 at 18:55 +0200, Andreas Hartmann wrote: Alex Williamson wrote: [...] Yep, I think the previous suggestion about reloading vfio_iommu_type1 with allow_unsafe_interrupts=1 will solve it. Yes! Works now. Success! Works means: Device is seen in VM. I couldn't test it up to now, because I don't have any driver in the VM for this device. I tested it as far as doing 'cat /dev/video0 /tmp/test'. The file grows, the device gets interrupts and `file` thinks it's a video (no input connected to the card). It has nothing to do with file permissions, you're getting EPERM at the point where we set the iommu type, which enables access to devices. By default we want an iommu which protects against malicious MSI attacks, which requires interrupt remapping on x86. Joerg has been working to add this for AMD since the hardware supports it, but for now, the above options lets us bypass the check. Thanks, Now, I have to check my problem with the filesystem first, which isn't cleanly unmounted. I suspect a few missing options for kernel compile. Next will be fglrx :-) for 3.4 Hmmm, is there a chance to get your extension isolated to get it compiled for 3.1, too? The patches are all layered on top of that branch, so you should be able to easily 'git show' to get patches or cherry-pick them across trees. I don't think there should be too much trouble backporting them. Thanks, Alex -- 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: AMD KVM Pci Passthrough reports device busy
Alex Williamson wrote: On Tue, 2012-06-05 at 18:55 +0200, Andreas Hartmann wrote: Alex Williamson wrote: [...] Yep, I think the previous suggestion about reloading vfio_iommu_type1 with allow_unsafe_interrupts=1 will solve it. Yes! Works now. Success! Works means: Device is seen in VM. I couldn't test it up to now, because I don't have any driver in the VM for this device. Well, I've got another problem now with 3.4: I can't pass through my PCIe device any more, which works fine without any problem with 3.1.10. I'm getting the following error in 3.4: Failed to assign irq for hostdev0: Input/output error Perhaps you are assigning a device that shares an IRQ with another device? qemu-kvm: -device pci-assign,host=04:00.0,id=hostdev0,configfd=19,bus=pci.0,addr=0x6: Device 'pci-assign' could not be initialized options kvm allow_unsafe_assigned_interrupts=1 is set. There are share IRQ's - but that's the same in 3.1.10. This VM is started with libvirt (virsh) the old fashioned way with the old qemu-kvm tool. Doesn't this work any more? BTW: I think libvirt / virsh isn't aware yet of the new vfio way, isn't it? Thanks, Andreas -- 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: AMD KVM Pci Passthrough reports device busy
On Tue, 2012-06-05 at 22:37 +0200, Andreas Hartmann wrote: Alex Williamson wrote: On Tue, 2012-06-05 at 18:55 +0200, Andreas Hartmann wrote: Alex Williamson wrote: [...] Yep, I think the previous suggestion about reloading vfio_iommu_type1 with allow_unsafe_interrupts=1 will solve it. Yes! Works now. Success! Works means: Device is seen in VM. I couldn't test it up to now, because I don't have any driver in the VM for this device. Well, I've got another problem now with 3.4: I can't pass through my PCIe device any more, which works fine without any problem with 3.1.10. I'm getting the following error in 3.4: Failed to assign irq for hostdev0: Input/output error Perhaps you are assigning a device that shares an IRQ with another device? qemu-kvm: -device pci-assign,host=04:00.0,id=hostdev0,configfd=19,bus=pci.0,addr=0x6: Device 'pci-assign' could not be initialized options kvm allow_unsafe_assigned_interrupts=1 is set. There are share IRQ's - but that's the same in 3.1.10. This VM is started with libvirt (virsh) the old fashioned way with the old qemu-kvm tool. Doesn't this work any more? Does this help: https://lkml.org/lkml/2012/6/1/261 Otherwise, dmesg and device info please. BTW: I think libvirt / virsh isn't aware yet of the new vfio way, isn't it? Correct, need to get it into the kernel and qemu first. Thanks, Alex -- 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: AMD KVM Pci Passthrough reports device busy
Alex Williamson wrote: On Tue, 2012-06-05 at 22:37 +0200, Andreas Hartmann wrote: Alex Williamson wrote: On Tue, 2012-06-05 at 18:55 +0200, Andreas Hartmann wrote: Alex Williamson wrote: [...] Yep, I think the previous suggestion about reloading vfio_iommu_type1 with allow_unsafe_interrupts=1 will solve it. Yes! Works now. Success! Works means: Device is seen in VM. I couldn't test it up to now, because I don't have any driver in the VM for this device. Well, I've got another problem now with 3.4: I can't pass through my PCIe device any more, which works fine without any problem with 3.1.10. I'm getting the following error in 3.4: Failed to assign irq for hostdev0: Input/output error Perhaps you are assigning a device that shares an IRQ with another device? qemu-kvm: -device pci-assign,host=04:00.0,id=hostdev0,configfd=19,bus=pci.0,addr=0x6: Device 'pci-assign' could not be initialized options kvm allow_unsafe_assigned_interrupts=1 is set. There are shared IRQ's - but that's the same in 3.1.10. This VM is started with libvirt (virsh) the old fashioned way with the old qemu-kvm tool. Doesn't this work any more? Does this help: https://lkml.org/lkml/2012/6/1/261 Yes - this fixed the problem! Thanks, Andreas -- 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: AMD KVM Pci Passthrough reports device busy
test On Tue, Jun 5, 2012 at 5:39 AM, Andreas Hartmann andihartm...@01019freenet.de wrote: Hello Alex, thanks for your efforts! Maybe, you already know that I'm suffering the same problem :-( with a GA-990XA-UD3 (990X chipset). On Mon, 04 Jun 2012 21:44:05 -0600 Alex Williamson alex.william...@redhat.com wrote: [...] I have a setup with an AMD 990FX system and a spare PVR-350 card that I installed to reproduce. The sad answer is that it's nearly impossible to assign PCI devices on these systems due to the aliasing of devices below the PCIe-to-PCI bridge (PCIe devices are much, much easier to assign). If you boot with amd_iommu_dump, you'll see some output like this: AMD-Vi: DEV_ALIAS_RANGE devid: 05:00.0 flags: 00 devid_to: 00:14.4 AMD-Vi: DEV_RANGE_END devid: 05:1f.7 here: AMD-Vi: DEV_ALIAS_RANGE devid: 06:00.0 flags: 00 devid_to: 00:14.4 AMD-Vi: DEV_RANGE_END devid: 06:1f.7 This means according to your description, the following devices have to be unbound here, too (:06:07.0 is the device I want to passthrough): :00:14.0 - ../../../../devices/pci:00/:00:14.0 :00:14.1 - ../../../../devices/pci:00/:00:14.1 :00:14.2 - ../../../../devices/pci:00/:00:14.2 :00:14.3 - ../../../../devices/pci:00/:00:14.3 :00:14.4 - ../../../../devices/pci:00/:00:14.4 :00:14.5 - ../../../../devices/pci:00/:00:14.5 :06:07.0 - ../../../../devices/pci:00/:00:14.4/:06:07.0 These are the following additional devices: 00:14.0 SMBus: Advanced Micro Devices [AMD] nee ATI SBx00 SMBus Controller (rev 42) 00:14.1 IDE interface: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 IDE Controller (rev 40) (prog-if 8a [Master SecP PriP]) 00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA) (rev 40) 00:14.3 ISA bridge: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 LPC host controller (rev 40) 00:14.4 PCI bridge: Advanced Micro Devices [AMD] nee ATI SBx00 PCI to PCI Bridge (rev 40) (prog-if 01 [Subtractive decode]) 00:14.5 USB controller: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI2 Controller (prog-if 10 [OHCI]) Among them is the sound device and the USB device - no good idea to disable them on a desktop. Disabling 00:14.1 seems to be possible (rmmod pata_atiixp works), but I'm getting errors after rebooting the system (the filesystems haven't been cleanly unmounted during shutdown). Anyway, I would have tested it, but I'm getting a compile error while compiling qemu. It complains about missing pci/header.h while processing hw/vfio_pci.c:49:24. I can't find any pci/header.h. Where should it come from? [...] The downside is that VFIO is strict about multifunction devices supporting ACS to prevent peer-to-peer between domains, so will require all of the 14.x devices to be bound to pci-stub as well. On my system, this includes an smbus controller, audio device, lpc controller, and usb device. If AMD could confirm this device doesn't allow peer-to-peer between functions, we could relax this requirement a bit. Please Joerg, could you take a look at this problem? Thanks, kind regards, Andreas -- 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 -- Sheng Qiu Texas A M University Room 332B Wisenbaker email: herbert1984...@gmail.com College Station, TX 77843-3259 -- 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: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560...
-Original Message- From: Kevin Wolf [mailto:kw...@redhat.com] Sent: Monday, June 04, 2012 9:51 PM To: Ren, Yongjie Cc: Marcelo Tosatti; Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560... Am 01.06.2012 10:31, schrieb Kevin Wolf: Am 01.06.2012 09:57, schrieb Ren, Yongjie: -Original Message- From: Marcelo Tosatti [mailto:mtosa...@redhat.com] Sent: Thursday, May 31, 2012 4:28 AM To: Ren, Yongjie Cc: Kevin Wolf; Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560... On Tue, May 22, 2012 at 07:40:29AM +, Ren, Yongjie wrote: -Original Message- From: Kevin Wolf [mailto:kw...@redhat.com] Sent: Monday, May 21, 2012 11:30 PM To: Ren, Yongjie Cc: Avi Kivity; kvm@vger.kernel.org; Liu, RongrongX Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560... Am 21.05.2012 11:45, schrieb Ren, Yongjie: -Original Message- From: Kevin Wolf [mailto:kw...@redhat.com] Sent: Monday, May 21, 2012 5:05 PM To: Avi Kivity Cc: Ren, Yongjie; kvm@vger.kernel.org Subject: Re: Biweekly KVM Test report, kernel 51bfd299... qemu a1fce560... Am 21.05.2012 10:27, schrieb Avi Kivity: On 05/21/2012 06:34 AM, Ren, Yongjie wrote: Hi All, This is KVM upstream test result against kvm.git 51bfd2998113e1f8ce8dcf853407b76a04b5f2a0 based on kernel 3.4.0-rc7, and qemu-kvm.git a1fce560c0e5f287ed65d2aaadb3e59578aaa983. We found 1 new bug and 1 bug got fixed in the past two weeks. New issue (1): 1. disk error when guest boot up via qcow2 image https://bugs.launchpad.net/qemu/+bug/1002121 -- Should be a regression on qemu-kvm. Kevin, is this the known regression in qcow2 or something new? If the commit ID is right, it must be something new. The regression that Marcelo found was fixed in 54e68143. Yes, it's right. This should be a new regression. I looked at the comment of 54e68143, and found it was not related the issue I reported. The Launchpad bug refers to commit e54f008ef, which doesn't include this fix indeed. So was the test repeated with a more current qemu-kvm version after filing the bug in Launchpad, or is the commit ID in this mail wrong? Latest commit 3fd9fedb in qemu-kvm master tree still has this issue. And, the commit ID provided in Launchpad is correct. Can you please check if the bug exists in upstream qemu.git as well? This bug doesn't exist on upstream qemu.git with latest commit: fd4567d9. So, it should only exists on qemu-kvm tree. Please bisect manually (not using git bisect), with the attached list of commits. These are the qemu - qemu-kvm merge commits in the range described as bad/good. The 1st bad commit in your attached list is abc551bd More detailed info: 171d2f2249a360d7d623130d3aa991418c53716d good fd453a24166e36a3d376c9bc221e520e3ee425afgood abc551bd456cf0407fa798395d83dc5aa35f6dbb bad 823ccf41509baa197dd6a3bef63837a6cf101ad8 bad Thanks, this points to the qcow2 v3 changes. Let's try to find the exact culprit. I have rebased the qcow2 patches on top of that good merge (fd453a24). Please apply the attached mbox on top of this merge: git checkout fd453a24 git am qcow2v3.mbox You can then start a git bisect between your new HEAD and fd453a24. Another thing you could try is if reverting e82dabd and bef0fd59 fixes the problem for you. After reverting bef0fd59, it can work fine. -- 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: AMD KVM Pci Passthrough reports device busy
Alex, This solution appears to be working for me as well on a GA-970-D3. I've been able to pass the Hauppauge 350 through to a Windows XP guest which has installed drivers and loaded it into my recording software (SageTV). I've got a few more things I want to clean up on my qemu start command but I'm very close to where I need to be now. Once I get a few more configurations finished I'll record some shows for a final test of functionality. Thank you for your time in assisting me, the vfio drivers are working exactly as expected so far. Chris -- 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: AMD KVM Pci Passthrough reports device busy
On Tue, 2012-06-05 at 22:07 -0500, Chris Sanders wrote: Alex, This solution appears to be working for me as well on a GA-970-D3. I've been able to pass the Hauppauge 350 through to a Windows XP guest which has installed drivers and loaded it into my recording software (SageTV). I've got a few more things I want to clean up on my qemu start command but I'm very close to where I need to be now. Once I get a few more configurations finished I'll record some shows for a final test of functionality. Thank you for your time in assisting me, the vfio drivers are working exactly as expected so far. Great, glad to hear it. You can expect performance to get better once we get this upstream. Interrupts are currently getting bounced through Qemu which adds overhead. Eventually we'll accelerate them through KVM. I'm still able to play static directly from the device using mplayer, so it doesn't seem to get in the way. Stay tuned for vfio upstream. Thanks, Alex -- 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: AMD KVM Pci Passthrough reports device busy
Great, glad to hear it. You can expect performance to get better once we get this upstream. Interrupts are currently getting bounced through Qemu which adds overhead. Eventually we'll accelerate them through KVM. I'm still able to play static directly from the device using mplayer, so it doesn't seem to get in the way. Stay tuned for vfio upstream. Thanks, Alex What would be the best way to stay up to date on the status of vfio? Subscribe to this mailing list, or something else? Chris -- 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: AMD KVM Pci Passthrough reports device busy
On Tue, 2012-06-05 at 22:31 -0500, Chris Sanders wrote: Great, glad to hear it. You can expect performance to get better once we get this upstream. Interrupts are currently getting bounced through Qemu which adds overhead. Eventually we'll accelerate them through KVM. I'm still able to play static directly from the device using mplayer, so it doesn't seem to get in the way. Stay tuned for vfio upstream. Thanks, Alex What would be the best way to stay up to date on the status of vfio? Subscribe to this mailing list, or something else? Yes, probably subscribe here and just filter vfio in the subject. Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PULL 00/20 1.2] kvm updates
On 06/05/2012 04:58 AM, Anthony Liguori wrote: On 06/05/2012 08:52 AM, Andreas Färber wrote: Am 04.06.2012 07:46, schrieb Anthony Liguori: On 05/22/2012 12:37 AM, Avi Kivity wrote: Please pull from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Pulled. Thanks. This broke the ppc build. Guys, why wasn't this tested? There's only three KVM targets to test compared to the 14 I'm struggling with... Is build bot running against uq/master? If it's not, maybe we should add it to build bot to catch this sort of thing. A build bot is overkill. I usually do a full build (and autotest), don't know how this was missed. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PULL 00/20 1.2] kvm updates
On 05.06.2012, at 09:42, Avi Kivity a...@redhat.com wrote: On 06/05/2012 04:58 AM, Anthony Liguori wrote: On 06/05/2012 08:52 AM, Andreas Färber wrote: Am 04.06.2012 07:46, schrieb Anthony Liguori: On 05/22/2012 12:37 AM, Avi Kivity wrote: Please pull from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Pulled. Thanks. This broke the ppc build. Guys, why wasn't this tested? There's only three KVM targets to test compared to the 14 I'm struggling with... Is build bot running against uq/master? If it's not, maybe we should add it to build bot to catch this sort of thing. A build bot is overkill. I usually do a full build (and autotest), don't know how this was missed. Not sure why it would be overkill. We have build bots running on more exotic hw (ppc and s390) with kvm available for that exact purpose. They're running either way - all we need to do is enable uq/master and we catch these before the next pull request :). Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PULL 00/20 1.2] kvm updates
On 2012-06-05 10:10, Alexander Graf wrote: On 05.06.2012, at 09:42, Avi Kivity a...@redhat.com wrote: On 06/05/2012 04:58 AM, Anthony Liguori wrote: On 06/05/2012 08:52 AM, Andreas Färber wrote: Am 04.06.2012 07:46, schrieb Anthony Liguori: On 05/22/2012 12:37 AM, Avi Kivity wrote: Please pull from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Pulled. Thanks. This broke the ppc build. Guys, why wasn't this tested? There's only three KVM targets to test compared to the 14 I'm struggling with... Is build bot running against uq/master? If it's not, maybe we should add it to build bot to catch this sort of thing. A build bot is overkill. I usually do a full build (and autotest), don't know how this was missed. Not sure why it would be overkill. We have build bots running on more exotic hw (ppc and s390) with kvm available for that exact purpose. They're running either way - all we need to do is enable uq/master and we catch these before the next pull request :). I think this makes some sense. uq/master is supposed to be the staging branch for generic and (at least) x86 kvm changes in QEMU. So it should cover at least their builds. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PULL 00/20 1.2] kvm updates
On 06/05/2012 03:42 PM, Avi Kivity wrote: On 06/05/2012 04:58 AM, Anthony Liguori wrote: On 06/05/2012 08:52 AM, Andreas Färber wrote: Am 04.06.2012 07:46, schrieb Anthony Liguori: On 05/22/2012 12:37 AM, Avi Kivity wrote: Please pull from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Pulled. Thanks. This broke the ppc build. Guys, why wasn't this tested? There's only three KVM targets to test compared to the 14 I'm struggling with... Is build bot running against uq/master? If it's not, maybe we should add it to build bot to catch this sort of thing. A build bot is overkill. I usually do a full build (and autotest), don't know how this was missed. Note that this error is specific to KVM on PowerPC. It doesn't affect qemu-system-ppc64 built on an x86_64 host. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PULL 00/20 1.2] kvm updates
On 06/05/2012 12:02 PM, Anthony Liguori wrote: On 06/05/2012 03:42 PM, Avi Kivity wrote: On 06/05/2012 04:58 AM, Anthony Liguori wrote: On 06/05/2012 08:52 AM, Andreas Färber wrote: Am 04.06.2012 07:46, schrieb Anthony Liguori: On 05/22/2012 12:37 AM, Avi Kivity wrote: Please pull from: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Pulled. Thanks. This broke the ppc build. Guys, why wasn't this tested? There's only three KVM targets to test compared to the 14 I'm struggling with... Is build bot running against uq/master? If it's not, maybe we should add it to build bot to catch this sort of thing. A build bot is overkill. I usually do a full build (and autotest), don't know how this was missed. Note that this error is specific to KVM on PowerPC. It doesn't affect qemu-system-ppc64 built on an x86_64 host. Ah, okay. In any case I take back my comment about overkill. An extra buildbot run is cheap and overkill is better than underkill. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
