On 05/11/2010 07:52 PM, Mohammed Gamal wrote:
- Add 's' and 'g' field checks on segment registers
- Correct SS checks for request and descriptor privilege levels
Signed-off-by: Mohammed Gamalm.gamal...@gmail.com
---
arch/x86/kvm/vmx.c | 73 +++
On 05/12/2010 09:11 PM, Stefano Stabellini wrote:
On Wed, 12 May 2010, Jamie Lokier wrote:
Stefano Stabellini wrote:
On Wed, 12 May 2010, Avi Kivity wrote:
It's useful if you have a one-line horizontal pattern you want to
propagate all over.
It might be useful
On 05/12/2010 05:57 PM, Stefano Stabellini wrote:
I guess even a src blt pitch of 0 could be useful there, however in
practice I think the only rop function that was written with this case in
mind has:
dstpitch -= bltwidth;
srcpitch -= bltwidth;
if (dstpitch 0 || srcpitch 0) {
/* is 0
David, if it's not too late, please pull the following
last minute fix into 2.6.34.
Thanks!
The following changes since commit de02d72bb3cc5b3d4c873db4ca8291723dd48479:
Merge branch 'master' of
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 (2010-05-10
22:53:41 -0700)
On Wed, 12 May 2010 18:29:57 -0700
Chris Wright chr...@sous-sol.org wrote:
The PCI config space bin_attr read handler has a hardcoded CAP_SYS_ADMIN
check to verify privileges before allowing a user to read device
dependent config space. This is meant to protect from an unprivileged
user
On 05/13/2010 04:29 AM, Chris Wright wrote:
The PCI config space bin_attr read handler has a hardcoded CAP_SYS_ADMIN
check to verify privileges before allowing a user to read device
dependent config space. This is meant to protect from an unprivileged
user potentially locking up the box.
When
mark_page_dirty is called with the mmu_lock spinlock held in set_spte.
Must find a way to move it outside of the spinlock section.
Oh, it's a serious problem. I have to consider it.
Avi, Marcelo,
Sorry but I have to say that mmu_lock spin_lock problem was completely out of
my mind.
On Thu, May 13, 2010 at 01:56:53PM +0300, Avi Kivity wrote:
On 05/13/2010 04:29 AM, Chris Wright wrote:
The PCI config space bin_attr read handler has a hardcoded CAP_SYS_ADMIN
check to verify privileges before allowing a user to read device
dependent config space. This is meant to protect
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/x86.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4b1433f..f54ec24 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1844,6 +1844,7 @@ static int
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/powerpc/kvm/book3s.c | 10 ++
arch/powerpc/kvm/booke.c | 15 ++-
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 11f226f..b998abf 100644
---
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/x86.c | 41 ++---
1 files changed, 2 insertions(+), 39 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index eedb23b..8b9e5ec 100644
--- a/arch/x86/kvm/x86.c
+++
Avi Kivity (7):
KVM: PPC: Add missing vcpu_load()/vcpu_put() in vcpu ioctls
KVM: x86: Add missing locking to arch specific vcpu ioctls
KVM: move vcpu locking to dispatcher for generic vcpu ioctls
KVM: x86: Lock arch specific vcpu ioctls centrally
KVM: s390: Centrally lock arch specific
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/powerpc/kvm/powerpc.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index e0fae7a..caeed7b 100644
--- a/arch/powerpc/kvm/powerpc.c
+++
All vcpu ioctls need to be locked, so instead of locking each one specifically
we lock at the generic dispatcher.
This patch only updates generic ioctls and leaves arch specific ioctls alone.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/ia64/kvm/kvm-ia64.c | 11 ---
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/s390/kvm/kvm-s390.c | 40 +---
1 files changed, 17 insertions(+), 23 deletions(-)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index e80f55e..28cd8fd 100644
--- a/arch/s390/kvm/kvm-s390.c
Now that all arch specific ioctls have centralized locking, it is easy to
move it to the central dispatcher.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/powerpc/kvm/powerpc.c | 11 ---
arch/s390/kvm/kvm-s390.c | 13 ++---
arch/x86/kvm/x86.c |2 --
On 13.05.2010, at 13:17, Avi Kivity wrote:
Avi Kivity (7):
KVM: PPC: Add missing vcpu_load()/vcpu_put() in vcpu ioctls
KVM: x86: Add missing locking to arch specific vcpu ioctls
KVM: move vcpu locking to dispatcher for generic vcpu ioctls
KVM: x86: Lock arch specific vcpu ioctls
On 05/13/2010 02:57 PM, Alexander Graf wrote:
Mind to give a high level overview on where you're moving which locks?
Um, looks like I forgot to fill in the patchset header. Sorry.
The patches move all vcpu ioctl locking from the individual ioctl
handlers (e.g.
On 05/13/2010 03:03 PM, Avi Kivity wrote:
On 05/13/2010 03:01 PM, Avi Kivity wrote:
On 05/13/2010 02:57 PM, Alexander Graf wrote:
Mind to give a high level overview on where you're moving which locks?
Um, looks like I forgot to fill in the patchset header. Sorry.
Gar, I actually wrote
On 13.05.2010, at 14:03, Avi Kivity wrote:
On 05/13/2010 03:03 PM, Avi Kivity wrote:
On 05/13/2010 03:01 PM, Avi Kivity wrote:
On 05/13/2010 02:57 PM, Alexander Graf wrote:
Mind to give a high level overview on where you're moving which locks?
Um, looks like I forgot to fill in the
On 05/13/2010 03:18 PM, Alexander Graf wrote:
[PATCH 0/7] Consolidate vcpu ioctl locking
In general, all vcpu ioctls need to take the vcpu mutex, but each one does it
(or not) individually. This is cumbersome and error prone.
This patchset moves all locking to a central place. This is
This is *NOT* a KVM issue, but may be worth adding into the FAQ...
We have a KVM host with 48Gb of RAM and run about 20 KVM clients on it.
After some time - different time depending on the kernel version - the
VM host kernel will start OOM-Killing the VM clients, even when there is
lots of
On 05/13/2010 03:20 PM, James Stevens wrote:
This is *NOT* a KVM issue, but may be worth adding into the FAQ...
We have a KVM host with 48Gb of RAM and run about 20 KVM clients on
it. After some time - different time depending on the kernel version -
the VM host kernel will start OOM-Killing
I'd go with 64-bit at 2GB and above. It's both faster and safer.
safer, how? (apart from no lowmem exhaust).
On a different subject, the qemu documentation says a guest VM can only
have 2Gb of memory - does this still apply when using a 64bit host O/S ?
The lowmem load is about 0.5% of
On Thu, May 13, 2010 at 03:39:20PM +0300, Avi Kivity wrote:
On 05/13/2010 03:20 PM, James Stevens wrote:
General advice seems to be, if you have more than 16Gb RAM then
you should run the VM host 64bit.
We didn't see this issue on a server with 32Gb running the same
set of VMs.
I'd
At Thu, 13 May 2010 04:46:46 +0900,
MORITA Kazutaka wrote:
On 2010/05/12 20:38, Kevin Wolf wrote:
I'll have a closer look at your code later, but one thing I noticed is
that the new block driver is something in between a protocol and a
format driver (just like vvfat, which should stop
On 05/13/2010 04:39 PM, James Stevens wrote:
I'd go with 64-bit at 2GB and above. It's both faster and safer.
safer, how? (apart from no lowmem exhaust).
Nothing apart from that (well, if you run nonpae you lose NX protection).
On a different subject, the qemu documentation says a guest
Stefano Stabellini wrote:
[]
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 9f61a01..81c443b 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
The same as with previous patch: Yellow screen
(instead of crashing), and two lines on the
stderr:
BUG: kvm_dirty_pages_log_enable_slot:
How to count and trace KVM perf events:
http://www.linux-kvm.org/page/Perf_events
I want to draw attention to this because traditional kvm_stat and
kvm_trace use has been moving over to the debugfs based tracing
mechanisms. Perhaps we can flesh out documentation and examples of
common perf
* Alan Cox (a...@lxorguk.ukuu.org.uk) wrote:
On Wed, 12 May 2010 18:29:57 -0700
Chris Wright chr...@sous-sol.org wrote:
The PCI config space bin_attr read handler has a hardcoded CAP_SYS_ADMIN
check to verify privileges before allowing a user to read device
dependent config space. This
Stefano Stabellini wrote:
I think we need to consider only dstpitch for a full invalidate. We
might be copying an offscreen bitmap into the screen, and srcpitch is
likely to be the bitmap width instead of the screen pitch.
Agreed.
Even when copying on-screen (or partially on-screen),
On 05/10/2010 06:58 PM, Anthony Liguori wrote:
Isn't this problem unrelated to this patch? I mean if I start qemu with
two ide devices can I specify from qemu command line which one I want to
boot from?
That's sort of what I'm asking. If you compare this approach to
extboot, extboot
Hello List,
please don't shout at me if the answer to my question is too obvious,
but in the German Linux Magazine I read an article about passing PCI
devices to KVM guests and the authors said that shared interrupt
funcionality has to be disabled which I read as it is possible to
disable shared
On 05/13/2010 07:57 PM, Dirk Gouders wrote:
Hello List,
please don't shout at me if the answer to my question is too obvious,
We won't shout at you.
but in the German Linux Magazine I read an article about passing PCI
devices to KVM guests and the authors said that shared interrupt
* Avi Kivity (a...@redhat.com) wrote:
On 05/13/2010 07:57 PM, Dirk Gouders wrote:
Hello List,
please don't shout at me if the answer to my question is too obvious,
We won't shout at you.
but in the German Linux Magazine I read an article about passing PCI
devices to KVM guests and the
* Alan Cox (a...@lxorguk.ukuu.org.uk) wrote:
I agree with the problem - but IMHO the fix is to require opening the file
checks CAP_SYS_something instead: not to hack the read method and make it
even weirder and more un-Linux than it is now.
This patch does that. Not as convenient from the
On Thu, 13 May 2010, Michael Tokarev wrote:
Stefano Stabellini wrote:
[]
diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c
index 9f61a01..81c443b 100644
--- a/hw/cirrus_vga.c
+++ b/hw/cirrus_vga.c
The same as with previous patch: Yellow screen
(instead of crashing), and two lines on the
Not sure I like the idea of running a 64bit user space kernel on top
of a 32bit host, prefer to re-install.
Can I just replace my kernel with a 64bit one, or do I have to
re-install the host O/S ?
You can run 32-bit userspace with a 64-bit kernel, or reinstall,
whichever you prefer.
I
On Thu, May 13, 2010 at 10:43:07AM -0700, Chris Wright wrote:
* Alan Cox (a...@lxorguk.ukuu.org.uk) wrote:
I agree with the problem - but IMHO the fix is to require opening the file
checks CAP_SYS_something instead: not to hack the read method and make it
even weirder and more un-Linux than
* Greg KH (g...@kroah.com) wrote:
On Thu, May 13, 2010 at 10:43:07AM -0700, Chris Wright wrote:
* Alan Cox (a...@lxorguk.ukuu.org.uk) wrote:
I agree with the problem - but IMHO the fix is to require opening the file
checks CAP_SYS_something instead: not to hack the read method and make it
Am 13.05.2010 um 14:29 schrieb Avi Kivity a...@redhat.com:
On 05/13/2010 03:18 PM, Alexander Graf wrote:
[PATCH 0/7] Consolidate vcpu ioctl locking
In general, all vcpu ioctls need to take the vcpu mutex, but each
one does it
(or not) individually. This is cumbersome and error prone.
Enable GRO by default for performance.
Signed-off-by: Shirley Ma x...@us.ibm.com
---
drivers/net/ixgbevf/ixgbevf_main.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ixgbevf/ixgbevf_main.c
b/drivers/net/ixgbevf/ixgbevf_main.c
index 40f47b8..1bbb05e
on 05/13/2010 10:48 PM dry...@sky-haven.net wrote the following:
Ar 10.05.10 10:46, scríobh Thanasis:
I have installed kvm (app-emulation/qemu-kvm-0.12.3-r1) on linux (a
laptop with gentoo linux) and MS Windows 7 as guest.
Here is what info I get about the network on each one:
1) on linux
On Wed, May 12, 2010 at 01:39:21AM +0300, Mohammed Gamal wrote:
This adds missing decoder flags for sub instructions (opcodes 0x2c - 0x2d)
Signed-off-by: Mohammed Gamal m.gamal...@gmail.com
---
arch/x86/kvm/emulate.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Applied
Linus,
please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git kvm-updates/2.6.34
To receive the following updates:
Dongxiao Xu (1):
KVM: x86: Call vcpu_load and vcpu_put in cpuid_update
Jan Kiszka (1):
KVM: VMX: blocked-by-sti must not defer NMI injections
Joerg Roedel
On Thu, May 13, 2010 at 9:24 AM, Avi Kivity a...@redhat.com wrote:
On 05/11/2010 07:52 PM, Mohammed Gamal wrote:
- Add 's' and 'g' field checks on segment registers
- Correct SS checks for request and descriptor privilege levels
Signed-off-by: Mohammed Gamalm.gamal...@gmail.com
---
On Thu, May 13, 2010 at 9:50 PM, Marcelo Tosatti mtosa...@redhat.com wrote:
On Wed, May 12, 2010 at 01:39:21AM +0300, Mohammed Gamal wrote:
This adds missing decoder flags for sub instructions (opcodes 0x2c - 0x2d)
Signed-off-by: Mohammed Gamal m.gamal...@gmail.com
---
On Mon, May 10, 2010 at 5:59 AM, Avi Kivity a...@redhat.com wrote:
On 04/21/2010 08:53 PM, Cam Macdonell wrote:
+
+ /* allocate/initialize space for interrupt handling */
+ s-eventfds = qemu_mallocz(s-nr_alloc_guests * sizeof(int *));
+ s-eventfd_table =
Greetings Hannes and co,
I have been spending a bit of time trying Megasas HBA emulation +
TCM_Loop + SG_IO with a Windows XP SP2 KVM guests.. So far, I noticed
that hw/scsi-generic.c:execute_command_run() using bdev_aio_ioctl()
appears to be broken for XP guests, which causes the first 36-byte
On Wed, May 12, 2010 at 02:44:03PM +0800, Huang Ying wrote:
In common cases, guest SRAO MCE will cause corresponding poisoned page
be un-mapped and SIGBUS be sent to QEMU-KVM, then QEMU-KVM will relay
the MCE to guest OS.
But it is reported that if the poisoned page is accessed in guest
I'm trying to pass a pcie-device into a kvm guest. qemu-kvm is started
by libvirt with this command:
[...]
Failed to assign irq for hostdev0: Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?
Found out what was causing the issue:
Current
* Alex Williamson (alex.william...@redhat.com) wrote:
Remove this check in an effort to allow kvm guests to run without
root privileges. This capability check doesn't seem to add any
security since the device needs to have already been added via the
assign device ioctl and the io actually
On Thu, May 13, 2010 at 12:51, Shirley Ma mashi...@us.ibm.com wrote:
Enable GRO by default for performance.
Signed-off-by: Shirley Ma x...@us.ibm.com
---
drivers/net/ixgbevf/ixgbevf_main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
On Thu, 2010-05-13 at 15:06 -0700, Chris Wright wrote:
* Alex Williamson (alex.william...@redhat.com) wrote:
Remove this check in an effort to allow kvm guests to run without
root privileges. This capability check doesn't seem to add any
security since the device needs to have already been
On Fri, 2010-05-14 at 05:43 +0800, Marcelo Tosatti wrote:
On Wed, May 12, 2010 at 02:44:03PM +0800, Huang Ying wrote:
@@ -1975,6 +1976,27 @@ static int __direct_map(struct kvm_vcpu
return pt_write;
}
+static void kvm_send_hwpoison_signal(struct kvm *kvm, gfn_t gfn)
+{
+
Also add some more constants.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
Do we need to rename task_xstate_cachep? It's not only for task struct now.
arch/x86/include/asm/i387.h |2 ++
arch/x86/include/asm/xsave.h |3 +++
arch/x86/kernel/i387.c |3 ++-
fpu_save() would be used later by KVM.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/include/asm/i387.h | 71 ++-
1 files changed, 43 insertions(+), 28 deletions(-)
diff --git a/arch/x86/include/asm/i387.h b/arch/x86/include/asm/i387.h
This patchset based on Avi's FPU API patchset.
Sheng Yang (3):
x86: Split fpu_save_init() to fpu_save() and fpu_clear()
x86: Export FPU API for KVM use
KVM: x86: Use FPU API
arch/x86/include/asm/i387.h | 73 ---
arch/x86/include/asm/kvm_host.h |
Convert KVM to use generic FPU API.
Signed-off-by: Sheng Yang sh...@linux.intel.com
---
arch/x86/include/asm/kvm_host.h | 18 +-
arch/x86/kvm/x86.c | 73 ---
2 files changed, 23 insertions(+), 68 deletions(-)
diff --git
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/x86/kvm/x86.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4b1433f..f54ec24 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1844,6 +1844,7 @@ static int
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/s390/kvm/kvm-s390.c | 40 +---
1 files changed, 17 insertions(+), 23 deletions(-)
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index e80f55e..28cd8fd 100644
--- a/arch/s390/kvm/kvm-s390.c
Now that all arch specific ioctls have centralized locking, it is easy to
move it to the central dispatcher.
Signed-off-by: Avi Kivity a...@redhat.com
---
arch/powerpc/kvm/powerpc.c | 11 ---
arch/s390/kvm/kvm-s390.c | 13 ++---
arch/x86/kvm/x86.c |2 --
On 05/10/2010 03:26 PM, Takuya Yoshikawa wrote:
No doubt get.org - get.opt is measurable, but get.opt-switch.opt is
problematic. Have you tried profiling to see where the time is spent
(well I can guess, clearing the write access from the sptes).
Sorry but no, and I agree with your guess.
On 05/13/2010 02:57 PM, Alexander Graf wrote:
Mind to give a high level overview on where you're moving which locks?
Um, looks like I forgot to fill in the patchset header. Sorry.
The patches move all vcpu ioctl locking from the individual ioctl
handlers (e.g.
64 matches
Mail list logo
