On 08/01/2011 11:00 PM, Umesh Deshpande wrote:
I kept this in migration.c to call qemu_savevm_state_begin. (The way it
is done currently. i.e. to keep access to FdMigrationState in migration.c)
Calling it from buffered_file.c would be inconsistent in that sense. or
we will have to call it from
On 08/01/2011 11:27 PM, Alex Williamson wrote:
On Sun, 2011-07-31 at 17:09 +0300, Avi Kivity wrote:
On 07/30/2011 02:58 AM, Benjamin Herrenschmidt wrote:
Due to our paravirt nature, we don't need to masquerade the MSI-X table
for example. At all. If the guest configures crap into it,
On 08/02/2011 04:27 AM, Benjamin Herrenschmidt wrote:
I have a feeling you'll be getting the same capabilities sooner or
later, or you won't be able to make use of S/R IOV VFs.
I'm not sure why you mean. We can do SR/IOV just fine (well, with some
limitations due to constraints with how
On 08/01/2011 10:53 PM, Michael S. Tsirkin wrote:
Just because a memory region becomes visible to the cpu is no reason
to have a callback. From the device perspective, it can't tell that
it happened.
BTW this is what qxl does, too, conceptually: on config writes, it peeks
at the bar to
On Tue, Aug 02, 2011 at 12:17:06PM +0300, Avi Kivity wrote:
On 08/01/2011 10:53 PM, Michael S. Tsirkin wrote:
Just because a memory region becomes visible to the cpu is no reason
to have a callback. From the device perspective, it can't tell that
it happened.
BTW this is what qxl
Hi,
On Thu, Jul 28, 2011 at 6:52 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-07-27 18:35, Vasilis Liaskovitis wrote:
Hi,
On Mon, Jul 25, 2011 at 3:18 PM, Jan Kiszka jan.kis...@siemens.com wrote:
Applying these 3 patches + hacks/fix on master doesn't solve the
initial CPU: not
On Sun, Jul 31, 2011 at 04:08:44AM -0400, Avi Kivity wrote:
On 07/29/2011 02:31 PM, Roedel, Joerg wrote:
On Thu, Jul 28, 2011 at 04:36:17AM -0400, Avi Kivity wrote:
Architecturally, PDPTEs are cached in the PDPTRs when CR3 is reloaded.
On SVM, it is not possible to implement this, but
On 2011-08-02 11:46, Vasilis Liaskovitis wrote:
Hi,
On Thu, Jul 28, 2011 at 6:52 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2011-07-27 18:35, Vasilis Liaskovitis wrote:
Hi,
On Mon, Jul 25, 2011 at 3:18 PM, Jan Kiszka jan.kis...@siemens.com wrote:
Applying these 3 patches + hacks/fix
On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote:
On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
[snip]
On x86, the USB controllers don't typically live behind a PCIe-to-PCI
bridge, so don't suffer the source identifier problem, but they do often
share an
From: Julia Lawall ju...@diku.dk
Use BUG_ON(x) rather than if(x) BUG();
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@ identifier x; @@
-if (x) BUG();
+BUG_ON(x);
@@ identifier x; @@
-if (!x) BUG();
+BUG_ON(!x);
// /smpl
Signed-off-by: Julia
kvm_mmu_pte_write is unsafe since we need to alloc pte_list_desc in the
function when spte is prefetched, unfortunately, we can not know how many
spte need to be prefetched on this path, that means we can use out of the
free pte_list_desc object in the cache, and BUG_ON() is triggered, also some
The idea is from Avi:
| tag instructions that are typically used to modify the page tables, and drop
| shadow if any other instruction is used
| The list would include, I'd guess, and, or, bts, btc, mov, xchg, cmpxchg, and
| cmpxchg8b
This patch is used to tag the instructions and in the later
Drop the shadow page if it is written by the instructions which is not
typically used to modify the page table
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
---
arch/x86/include/asm/kvm_host.h |4 ++--
arch/x86/kvm/mmu.c |6 +++---
arch/x86/kvm/paging_tmpl.h
Remove the same code between emulator_pio_in_emulated and
emulator_pio_out_emulated
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
---
arch/x86/kvm/x86.c | 59 ++-
1 files changed, 26 insertions(+), 33 deletions(-)
diff --git
We usually use repeat string instructions to clear the page, for example,
we call memset to clear a page table, stosb is used in this function, and
repeated for 1024 times, that means we should occupy mmu lock for 1024 times
and walking shadow page cache for 1024 times, it is terrible
In fact, if
Directly Use mmu_page_zap_pte to zap spte in FNAME(invlpg), also remove the
same code between FNAME(invlpg) and FNAME(sync_page)
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
---
arch/x86/kvm/mmu.c | 16 ++--
arch/x86/kvm/paging_tmpl.h | 42
Fast prefetch spte for the unsync shadow page on invlpg path
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
---
arch/x86/include/asm/kvm_host.h |3 +--
arch/x86/kvm/mmu.c | 37 +++--
arch/x86/kvm/paging_tmpl.h | 23
In kvm_mmu_pte_write, we do not need to alloc shadow page, so calling
kvm_mmu_free_some_pages is really unnecessary
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
---
arch/x86/kvm/mmu.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/mmu.c
kvm_mmu_pte_write is too long, we split it for better readable
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
---
arch/x86/kvm/mmu.c | 189 +++-
1 files changed, 113 insertions(+), 76 deletions(-)
diff --git a/arch/x86/kvm/mmu.c
- Original Message -
On 07/29/11 06:53, Amos Kong wrote:
This test adds a usb storage for the guest, and do some check from
monitor and
inside the guest.
It's not very stable, could you help to review if something is
wrong?
Not stable means what exactly?
I found you had
Sometimes, we only modify the last one byte of a pte to update status bit,
for example, clear_bit is used to clear r/w bit in linux kernel and 'andb'
instruction is used in this function, in this case, kvm_mmu_pte_write will
treat it as misaligned access, and the shadow page table is zapped
Detecting write-flooding does not work well, when we handle page written, if
the last speculative spte is not accessed, we treat the page is
write-flooding, however, we can speculative spte on many path, such as pte
prefetch, page synced, that means the last speculative spte may be not point
to
On 08/01/2011 06:27 PM, Marcelo Tosatti wrote:
As noted by the original commit. Probably kept in qemu-kvm
due to a mismerge.
commit 7d0adcd6d57149d4e9ec66f3a1c171df2bea2775
Author: aurel32aurel32@c046a42c-6fe2-441c-8c8c-71466251a162
Date: Fri Oct 24 13:12:42 2008 +
hw/pc: don't
On 08/02/2011 02:28 PM, Avi Kivity wrote:
I noticed the same thing on the large upstream merge - this code is
now gone.
last upstream merge.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
This test adds a usb storage for the guest, and do some check from monitor and
inside the guest.
Changes from v1:
- use old options to add a usb disk to guest
'-usbdevice disk:format=qcow2:/tmp/usbdevice.qcow2'
- identify device name of new disk by '/dev/disk/by-path/'
- match device with the
On 08/02/2011 02:07 PM, Xiao Guangrong wrote:
The idea is from Avi:
| tag instructions that are typically used to modify the page tables, and drop
| shadow if any other instruction is used
| The list would include, I'd guess, and, or, bts, btc, mov, xchg, cmpxchg, and
| cmpxchg8b
This patch is
Add checks for KVM_CAP_ASSIGN_DEV_IRQ (MSI) and KVM_CAP_DEVICE_MSIX, do
not set up MSI/MSI-X if the required kernel features are missing.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git
On 08/02/2011 12:31 PM, Roedel, Joerg wrote:
On Sun, Jul 31, 2011 at 04:08:44AM -0400, Avi Kivity wrote:
On 07/29/2011 02:31 PM, Roedel, Joerg wrote:
On Thu, Jul 28, 2011 at 04:36:17AM -0400, Avi Kivity wrote:
Architecturally, PDPTEs are cached in the PDPTRs when CR3 is reloaded.
On 08/01/2011 06:27 PM, Marcelo Tosatti wrote:
The information can be inferred from CPU_PUT_FULL_STATE and
bios_enabled.
Looks good.
--
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
On 08/02/2011 12:34 PM, Michael S. Tsirkin wrote:
On Tue, Aug 02, 2011 at 12:17:06PM +0300, Avi Kivity wrote:
On 08/01/2011 10:53 PM, Michael S. Tsirkin wrote:
Just because a memory region becomes visible to the cpu is no reason
to have a callback. From the device perspective,
On 08/01/2011 10:22 PM, Richard Henderson wrote:
On 07/31/2011 10:57 AM, Avi Kivity wrote:
+pci_register_bar_region(dev, 3, PCI_BASE_ADDRESS_SPACE_IO,
+d-cmd646_bar[2].cmd);
Typo: cmd646_bar[1].
Thanks, fixed.
--
error compiling committee.c: too many arguments to function
--
To
The following are patches I propose for fixing the bug discovered by Bandan
Das and discussed in the Nested VMX - L1 hangs on running L2 thread.
The first patch should fix the originally-reported bug, as explained in the
aforementioned thread: A new x86_op read_l1_tsc() is called L1's TSC is
KVM assumed in several places that reading the TSC MSR returns the value for
L1. This is incorrect, because when L2 is running, the correct TSC read exit
emulation is to return L2's value.
We therefore add a new x86_ops function, read_l1_tsc, to use in places that
specifically need to read the L1
This patch fixes two corner cases in nested (L2) handling of TSC-related
issues:
1. Somewhat suprisingly, according to the Intel spec, if L1 allows WRMSR to
the TSC MSR without an exit, then this should set L1's TSC value itself - not
offset by vmcs12.TSC_OFFSET (like was wrongly done in the
When the TSC MSR is read by an L2 guest (when L1 allowed this MSR to be
read without exit), we need to return L2's notion of the TSC, not L1's.
The current code incorrectly returned L1 TSC, because svm_get_msr() was also
used in x86.c where this was assumed, but now that these places call the new
On Tue, 2011-08-02 at 12:12 +0300, Avi Kivity wrote:
On 08/02/2011 04:27 AM, Benjamin Herrenschmidt wrote:
I have a feeling you'll be getting the same capabilities sooner or
later, or you won't be able to make use of S/R IOV VFs.
I'm not sure why you mean. We can do SR/IOV just
On Tue, Aug 02, 2011 at 08:34:32AM -0400, Avi Kivity wrote:
On 08/02/2011 12:31 PM, Roedel, Joerg wrote:
On Sun, Jul 31, 2011 at 04:08:44AM -0400, Avi Kivity wrote:
On 07/29/2011 02:31 PM, Roedel, Joerg wrote:
On Thu, Jul 28, 2011 at 04:36:17AM -0400, Avi Kivity wrote:
On 08/02/2011 03:58 PM, Benjamin Herrenschmidt wrote:
What you mean 2-level is two passes through two trees (ie 6 or 8 levels
right ?).
(16 or 25)
25 levels ? You mean 25 loads to get to a translation ? And you get any
kind of performance out of that ? :-)
Aggressive partial
On Tue, Aug 2, 2011 at 12:24 PM, Jan Kiszka jan.kis...@siemens.com wrote:
FWIW, I've pushed my tree here:
git://git.kiszka.org/qemu-kvm.git queues/cpu-hotplug
thanks. Your cpu-hotplug tree or today's git-master (commit
dacdc4b10bafbb21120e1c24a9665444768ef999) works.
Previously I tested the
Hi,
I found you had added new cmdline support of usb(ahci,usb2) for autotest.
But it's not supported right now.
12:42:16 INFO | (qemu) *** EHCI support is under development ***
It should work fine nevertheless. EHCI still lacks some stuff such as
migration support, thats why I didn't
On Tue, 2011-08-02 at 11:27 +1000, Benjamin Herrenschmidt wrote:
It's a shared address space. With a basic configuration on p7ioc for
example we have MMIO going from 3G to 4G (PCI side addresses). BARs
contain the normal PCI address there. But that 1G is divided in 128
segments of equal size
From: root r...@dhcp-26-193.brq.redhat.com
cgroup.py:
* structure for different cgroup subtests
* contains basic cgroup-memory test
cgroup_common.py:
* library for cgroup handling (intended to be used from kvm test in the future)
* universal smoke_test for every module
cgroup_client.py:
*
Hi guys,
this test is a basic structure for cgroup testing. It includes memory (mount -t
cgroup -o memory ...) test as an example.
Please let me know if you like this structure so I can make additional cgroup
subtests.
Regards,
Lukáš
--
To unsubscribe from this list: send the line
On Tue, 2011-08-02 at 22:58 +1000, Benjamin Herrenschmidt wrote:
Don't worry, it took me a while to get my head around the HW :-) SR-IOV
VFs will generally not have limitations like that no, but on the other
hand, they -will- still require 1 VF = 1 group, ie, you won't be able to
take a
On 08/02/11 11:17, Avi Kivity wrote:
On 08/01/2011 10:53 PM, Michael S. Tsirkin wrote:
Just because a memory region becomes visible to the cpu is no reason
to have a callback. From the device perspective, it can't tell that
it happened.
BTW this is what qxl does, too, conceptually: on
On Mon, 01 Aug 2011 18:26:23 +0300, Sasha Levin levinsasha...@gmail.com wrote:
On Mon, 2011-08-01 at 20:42 +0530, Aneesh Kumar K.V wrote:
On Mon, 1 Aug 2011 17:08:22 +0300, Sasha Levin levinsasha...@gmail.com
wrote:
This patch adds support for the UNIX extensions to 9p2000.
On Tue, 2011-08-02 at 14:27 +0200, Jan Kiszka wrote:
Add checks for KVM_CAP_ASSIGN_DEV_IRQ (MSI) and KVM_CAP_DEVICE_MSIX, do
not set up MSI/MSI-X if the required kernel features are missing.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c |6 --
1 files
On 2011-08-02 19:02, Alex Williamson wrote:
On Tue, 2011-08-02 at 14:27 +0200, Jan Kiszka wrote:
Add checks for KVM_CAP_ASSIGN_DEV_IRQ (MSI) and KVM_CAP_DEVICE_MSIX, do
not set up MSI/MSI-X if the required kernel features are missing.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
On Tue, 2011-08-02 at 18:28 +1000, David Gibson wrote:
On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote:
On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
[snip]
On x86, the USB controllers don't typically live behind a PCIe-to-PCI
bridge, so don't suffer the
On Tue, 2011-08-02 at 12:14 -0600, Alex Williamson wrote:
On Tue, 2011-08-02 at 18:28 +1000, David Gibson wrote:
On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote:
On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote:
[snip]
On x86, the USB controllers don't
This patch adds support for the UNIX extensions to 9p2000.
Supporting thses extensions allow us to transperantly mount UNIX directories
without missing features such as symlinks.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/virtio-9p.h |4 +-
This patch adds 2 new flags:
--rootfs [path] - Specifies a path to use as rootfs. The path will be mounted
using virtio-9p and booted from.
Easiest way to test it is to mount the sample image we recommend with kvm tool
(http://wiki.qemu.org/download/linux-0.2.img.bz2) and mounting it somewhere.
On Tue, Aug 02, 2011 at 07:10:54PM +0800, Xiao Guangrong wrote:
Fast prefetch spte for the unsync shadow page on invlpg path
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
---
arch/x86/include/asm/kvm_host.h |3 +--
arch/x86/kvm/mmu.c | 37
On Fri, Jul 29, 2011 at 04:57:25PM -0400, Umesh Deshpande wrote:
In the migration thread, qemu_mutex is released during the most time consuming
part. i.e. during is_dup_page which identifies the uniform data pages and
during
the put_buffer. qemu_mutex is also released while blocking on select
On Fri, Jul 29, 2011 at 04:57:26PM -0400, Umesh Deshpande wrote:
This patch creates a separate dirty bitmap for each slot. Currently dirty
bitmap
is created for addresses ranging from 0 to the end address of the last memory
slot. Since the memslots are not necessarily contiguous, current
On Tue, Aug 02, 2011 at 12:34:57PM +0200, Julia Lawall wrote:
From: Julia Lawall ju...@diku.dk
Use BUG_ON(x) rather than if(x) BUG();
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@ identifier x; @@
-if (x) BUG();
+BUG_ON(x);
@@
On 0, Nadav Har'El n...@il.ibm.com wrote:
The following are patches I propose for fixing the bug discovered by Bandan
Das and discussed in the Nested VMX - L1 hangs on running L2 thread.
The first patch should fix the originally-reported bug, as explained in the
aforementioned thread: A new
...@xenotime.net
---
arch/x86/kvm/Kconfig |2 ++
1 file changed, 2 insertions(+)
--- linux-next-20110802.orig/arch/x86/kvm/Kconfig
+++ linux-next-20110802/arch/x86/kvm/Kconfig
@@ -22,6 +22,8 @@ config KVM
depends on HAVE_KVM
# for device assignment:
depends on PCI
Thanks Bandan and Nadav,
I can confirm that these patches clear up the nVMX hang bug on my end. I don't
have any AMD hardware on-hand to test the SVM change, unfortunately.
Thanks for all the work on this!
-Matt McGill
On Aug 2, 2011, at 3:24 PM, Bandan Das wrote:
On 0, Nadav Har'El
On Tue, 2011-08-02 at 19:32 +0200, Jan Kiszka wrote:
On 2011-08-02 19:02, Alex Williamson wrote:
On Tue, 2011-08-02 at 14:27 +0200, Jan Kiszka wrote:
Add checks for KVM_CAP_ASSIGN_DEV_IRQ (MSI) and KVM_CAP_DEVICE_MSIX, do
not set up MSI/MSI-X if the required kernel features are missing.
When trying to map an alias of a ram region, where the alias starts at
address A and we map it into address B, and A B, we had an arithmetic
underflow. Because we use unsigned arithmetic, the underflow converted
into a large number which failed addrrange_intersects() tests.
The concrete example
On Tue, 2 Aug 2011, Avi Kivity wrote:
When trying to map an alias of a ram region, where the alias starts at
address A and we map it into address B, and A B, we had an arithmetic
underflow. Because we use unsigned arithmetic, the underflow converted
into a large number which failed
On 08/03/2011 12:15 AM, malc wrote:
On Tue, 2 Aug 2011, Avi Kivity wrote:
When trying to map an alias of a ram region, where the alias starts at
address A and we map it into address B, and A B, we had an arithmetic
underflow. Because we use unsigned arithmetic, the underflow converted
On Tue, Aug 02, 2011 at 09:34:58AM -0600, Alex Williamson wrote:
On Tue, 2011-08-02 at 22:58 +1000, Benjamin Herrenschmidt wrote:
Don't worry, it took me a while to get my head around the HW :-) SR-IOV
VFs will generally not have limitations like that no, but on the other
hand, they
On 08/02/2011 01:50 PM, Avi Kivity wrote:
struct AddrRange {
-uint64_t start;
-uint64_t size;
+int64_t start;
+int64_t size;
I'm must say I'm not keen on this. My primary objection is that
a range can no longer properly represent the entire address space.
Or, indeed,
On 08/03/2011 12:59 AM, Richard Henderson wrote:
On 08/02/2011 01:50 PM, Avi Kivity wrote:
struct AddrRange {
-uint64_t start;
-uint64_t size;
+int64_t start;
+int64_t size;
I'm must say I'm not keen on this. My primary objection is that
a range can no longer
On 08/02/2011 03:06 PM, Avi Kivity wrote:
I don't think there's any cpu which has a real 64-bit physical
address space? Don't they all truncate it?
I don't know. You're right that x86_64 does, at 48 bits.
The alpha system I'm trying to emulate does, at 50 bits.
I guess if IBM agrees wrt
On Thu, Jul 28, 2011 at 10:59 PM, Amos Kong ak...@redhat.com wrote:
This test does some basic operation on the virtual floppy,
it supports both Linux and Windows guests.
Looks good to me. I've removed the pre command and handled the floppy
creation in the test code, please check it out:
On Tue, 2011-08-02 at 17:29 -0400, Konrad Rzeszutek Wilk wrote:
On Tue, Aug 02, 2011 at 09:34:58AM -0600, Alex Williamson wrote:
On Tue, 2011-08-02 at 22:58 +1000, Benjamin Herrenschmidt wrote:
Don't worry, it took me a while to get my head around the HW :-) SR-IOV
VFs will generally
On Tue, Aug 02, 2011 at 12:35:19PM -0600, Alex Williamson wrote:
On Tue, 2011-08-02 at 12:14 -0600, Alex Williamson wrote:
On Tue, 2011-08-02 at 18:28 +1000, David Gibson wrote:
On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote:
On Sat, 2011-07-30 at 09:58 +1000, Benjamin
On Tue, 2 Aug 2011 21:46:28 +0300, Sasha Levin levinsasha...@gmail.com wrote:
This patch adds support for the UNIX extensions to 9p2000.
Supporting thses extensions allow us to transperantly mount UNIX directories
without missing features such as symlinks.
Signed-off-by: Sasha Levin
On Tue, 2 Aug 2011 21:46:29 +0300, Sasha Levin levinsasha...@gmail.com wrote:
This patch adds 2 new flags:
--rootfs [path] - Specifies a path to use as rootfs. The path will be mounted
using virtio-9p and booted from.
Easiest way to test it is to mount the sample image we recommend with
On Wed, 2011-08-03 at 12:04 +1000, David Gibson wrote:
On Tue, Aug 02, 2011 at 12:35:19PM -0600, Alex Williamson wrote:
On Tue, 2011-08-02 at 12:14 -0600, Alex Williamson wrote:
On Tue, 2011-08-02 at 18:28 +1000, David Gibson wrote:
On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex
Dear KVM Gurus:
I am developing a system on KVM with 2 guest OSes: one is a
real-time operating system without a TCP/IP stack; the other is Linux.
What's the easiest method for inter-domain communication? I am aware
of Nahanni for shared memory communication in KVM, but it requires a
PCI
This test adds a usb storage for the guest, and do some check from monitor and
inside the guest.
Changes from v1:
- use old options to add a usb disk to guest
'-usbdevice disk:format=qcow2:/tmp/usbdevice.qcow2'
- identify device name of new disk by '/dev/disk/by-path/'
- match device with the
On 07/23/2011 09:42 AM, Paul Mackerras wrote:
With a KVM guest operating in SMT4 mode (i.e. 4 hardware threads per
core), whenever a CPU goes idle, we have to pull all the other
hardware threads in the core out of the guest, because the H_CEDE
hcall is handled in the kernel. This is
76 matches
Mail list logo
