On Tue, May 29, 2012 at 09:51:09AM +0200, Jan Kiszka wrote:
On 2012-05-28 15:39, Michael S. Tsirkin wrote:
On Mon, May 28, 2012 at 03:29:58PM +0200, Jan Kiszka wrote:
On 2012-05-28 15:21, Michael S. Tsirkin wrote:
On Mon, May 28, 2012 at 02:51:25PM +0200, Jan Kiszka wrote:
On 2012-05-28
On Tue, 2012-05-29 at 12:26 +0300, Avi Kivity wrote:
On 05/29/2012 10:47 AM, Jan Kiszka wrote:
Under what conditions would the kernel not support ioport access via sysfs?
No clue. The oldest kernel I checked (2.6.16) does not contain traces it
would refuse to provide access.
Anthony Liguori anth...@codemonkey.ws wrote:
On 05/28/2012 06:20 PM, Juan Quintela wrote:
Hi
Please send in any agenda items you are interested in covering.
I'm in China for the next two weeks and this time is now pretty
inconvenient. Unless there's anything that requires urgent discussion
On Mon, 2012-05-28 at 15:03 +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
If the kernel does not support ioport access via sysfs, passthrough can
only help if the unlikely case that a port = 0x3ff is provided by the
device. So drop this to simplify the code and to allow
On 05/29/2012 04:47 PM, Alex Williamson wrote:
On Tue, 2012-05-29 at 12:26 +0300, Avi Kivity wrote:
On 05/29/2012 10:47 AM, Jan Kiszka wrote:
Under what conditions would the kernel not support ioport access via
sysfs?
No clue. The oldest kernel I checked (2.6.16) does not
On Mon, May 28, 2012 at 4:18 PM, bugzilla-dae...@bugzilla.kernel.org wrote:
When I am doing a recursive grep on my Clearcase view using a 3rd party
program
called Windows Grep. On every run, the VM would crash (windows kernel crash
where the cause is reported as unknown by Microsoft) up
On 05/25/2012 03:59 AM, Marcelo Tosatti wrote:
The problem with enabling PCID for the L2 guest is that it can share same
PCID
values with the L1 hypervisor.
However, if the L1 hypervisor enables and configures VPID (given that
the L0 hypervisor emulates and exposes it), there is
On 05/28/2012 05:44 PM, Andrea Arcangeli wrote:
On Mon, May 28, 2012 at 05:40:08PM +0300, Avi Kivity wrote:
Yes, I see it now. Adjusting mask is incorrect since we won't have the
same adjustment on release. I'll apply the patch for 3.5.
Sounds great to me. One thing I'm not sure about is
On 05/22/2012 06:23 AM, Xudong Hao wrote:
Re-send
Enabling Access bit when doing memory swapping.
Changes from v2:
-Still using claer_bit() function to make sure it's atomic operation.
Thanks, applied.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe
On Mon, 2012-05-28 at 15:03 +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
If the kernel does not support ioport access via sysfs, passthrough can
only help if the unlikely case that a port = 0x3ff is provided by the
device. So drop this to simplify the code and to allow
From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Size is not needed to return one from pre-allocated objects.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
arch/x86/kvm/mmu.c | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git
On 2012-05-29 16:41, Alex Williamson wrote:
On Mon, 2012-05-28 at 15:03 +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
If the kernel does not support ioport access via sysfs, passthrough can
only help if the unlikely case that a port = 0x3ff is provided by the
device. So
As suggested by Alex: Instead of failing if the kernel does not allow us
to speak to an ioport region, warn the user but, hide the region and
continue.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
On Tue, 2012-05-29 at 19:04 +0200, Jan Kiszka wrote:
As suggested by Alex: Instead of failing if the kernel does not allow us
to speak to an ioport region, warn the user but, hide the region and
continue.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/device-assignment.c |9
On 05/29/2012 08:04 PM, Jan Kiszka wrote:
As suggested by Alex: Instead of failing if the kernel does not allow us
to speak to an ioport region, warn the user but, hide the region and
continue.
Should we not, in addition, abort if the region is actually used? A
guest malfunction is likely if
On Tue, 2012-05-29 at 20:13 +0300, Avi Kivity wrote:
On 05/29/2012 08:04 PM, Jan Kiszka wrote:
As suggested by Alex: Instead of failing if the kernel does not allow us
to speak to an ioport region, warn the user but, hide the region and
continue.
Should we not, in addition, abort if
as a cross architecture solution.
These patches, as well as the PCI support patches and IOMMU group
infrastructure can be found in git here:
git://github.com/awilliam/linux-vfio.git (iommu-group-vfio-next-20120529)
A qemu tree including a vfio-pci driver capable of assigning PCI
devices to Qemu guests
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
Documentation/vfio.txt | 315
1 file changed, 315 insertions(+)
create mode 100644 Documentation/vfio.txt
diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
new file mode
VFIO is a secure user level driver for use with both virtual machines
and user level drivers. VFIO makes use of IOMMU groups to ensure the
isolation of devices in use, allowing unprivileged user access. It's
intended that VFIO will replace KVM device assignment and UIO drivers
(in cases where
This VFIO IOMMU backend is designed primarily for AMD-Vi and Intel
VT-d hardware, but is potentially usable by anything supporting
similar mapping functionality. We arbitrarily call this a Type1
backend for lack of a better name. This backend has no IOVA
or host memory mapping restrictions for
https://bugzilla.kernel.org/show_bug.cgi?id=43311
Michael Tokarev m...@tls.msk.ru changed:
What|Removed |Added
CC||m...@tls.msk.ru
---
Introduce a common function to abstract spte write-protect to
cleanup the code
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 58 +++
1 files changed, 31 insertions(+), 27 deletions(-)
diff --git
The reture value of __rmap_write_protect is either 1 or 0, use
true/false instead of these
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu.c
Changlog:
- disable fast page fault for soft mmu, let it only works for direct sptes.
- optimize spte_has_volatile_bits() and mmu_spte_update()
Performance result:
(The benchmark can be found at: http://www.spinics.net/lists/kvm/msg73011.html)
before
Export the present bit of page fault error code, the later patch
will use it
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/vmx.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index
mmu_spte_update() is the common function, we can easily audit the path
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 33 -
1 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kvm/mmu.c
This bit indicates whether the spte can be writable on MMU, that means
the corresponding gpte is writable and the corresponding gfn is not
protected by shadow page protection
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c | 41
If the the present bit of page fault error code is set, it indicates
the shadow page is populated on all levels, it means what we do is
only modify the access bit which can be done out of mmu-lock
Currently, in order to simplify the code, we only fix the page fault
caused by write-protect on the
To see what happen on this path and help us to optimize it
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmu.c |2 ++
arch/x86/kvm/mmutrace.h | 38 ++
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git
The P bit of page fault error code is missed in this tracepoint, fix it by
passing the full error code
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
arch/x86/kvm/mmutrace.h|7 +++
arch/x86/kvm/paging_tmpl.h |3 +--
2 files changed, 4 insertions(+), 6
Document fast page fault and mmu-lock in locking.txt
Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
---
Documentation/virtual/kvm/locking.txt | 134 -
1 files changed, 133 insertions(+), 1 deletions(-)
diff --git
于 2012年05月28日 21:28, Avi Kivity 写道:
On 05/28/2012 08:25 AM, Yanfei Zhang wrote:
Dou you have any comments about this patch set?
I still have a hard time understanding why it is needed. If the host
crashes, there is no reason to look at guest state; the host should
survive no matter what
On 2012-05-28 16:06, Avi Kivity wrote:
On 05/28/2012 04:03 PM, Jan Kiszka wrote:
From: Jan Kiszka jan.kis...@siemens.com
If the kernel does not support ioport access via sysfs, passthrough can
only help if the unlikely case that a port = 0x3ff is provided by the
device. So drop this to
On 2012-05-28 15:39, Michael S. Tsirkin wrote:
On Mon, May 28, 2012 at 03:29:58PM +0200, Jan Kiszka wrote:
On 2012-05-28 15:21, Michael S. Tsirkin wrote:
On Mon, May 28, 2012 at 02:51:25PM +0200, Jan Kiszka wrote:
On 2012-05-28 14:39, Michael S. Tsirkin wrote:
On Fri, May 25, 2012 at
Luiz Capitulino lcapitul...@redhat.com writes:
On Mon, 28 May 2012 12:17:04 +0100
Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote:
What we need to decide is whether it's okay to drop QEMU VLANs
completely and change dump command-line syntax?
I'd vote for dropping it.
I think vlan-hub
On 05/28/12 11:30, Avi Kivity wrote:
On 05/25/2012 11:36 AM, Veruca Salt wrote:
Avi- would love to test out 1.1, as we are currently using the ehci method
which has been frozen at 'experimental' for so long.
Is there any user documentation on the xhci methods?
Copying qemu-devel, where
On 05/28/2012 06:20 PM, Juan Quintela wrote:
Hi
Please send in any agenda items you are interested in covering.
I'm in China for the next two weeks and this time is now pretty inconvenient.
Unless there's anything that requires urgent discussion on the phone, I'd prefer
to just handle
No longer needed since device assignment stopped using it.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
Provided pci-assign: Drop support for raw ioport access is applied.
qemu-kvm.c| 93 -
qemu-kvm.h|9 -
On 05/29/2012 10:47 AM, Jan Kiszka wrote:
Under what conditions would the kernel not support ioport access via sysfs?
No clue. The oldest kernel I checked (2.6.16) does not contain traces it
would refuse to provide access.
I guess this was added first, and sysfs support was added later
Hi,
We are trying to do the patching of the privileged instructions of
guest from host side (instead of guest kernel patching itself). For this
we first need to map the magic page which is currently being done via
hypercall from guest.
We tried a few approaches. When we map the magic page
-Original Message-
From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org] On
Behalf Of cs5070214
Sent: Tuesday, May 29, 2012 8:12 PM
To: kvm-ppc@vger.kernel.org
Subject: Mapping magic page from host side
Hi,
We are trying to do the patching of the
Hi Dushyant,
I think that may be you should allow guest to complete some basic
initialization, for example create proper MMU mappings for itself.
Are you sure that magic page tlb entry didn't get overwritten by some other
guest tlb entry?
-Varun
-Original Message-
From:
42 matches
Mail list logo
