On 05/25/2011 09:18 PM, Marcelo Tosatti wrote:
Commit fa4491a6b667304 moved the permission check for io instructions
to the -check_perm callback. It failed to copy the port value from RDX
register for string and in,out ax,dx instructions.
Fix it by reading RDX register at decode stage when
Allow specifying an optional parameter when registering an
ioport range. The callback functions provided by the registering
module will be called with the same parameter.
This may be used to keep context during callbacks on IO operations.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
Add a very simple allocation of ioports.
This prevents the need to coordinate ioports between different
modules.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/ioport.h | 11 +--
tools/kvm/ioport.c | 36 ++--
Since ioports now has the ability to pass context to its
callbacks, we can implement multiple blk devices more efficiently.
We can get a ptr to the 'current' blk dev on each ioport call, which
means that we don't need to keep track of the blk device allocation
and ioport distribution within the
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/hw/vesa.c|7 +++
tools/kvm/include/kvm/ioport.h |2 --
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/tools/kvm/hw/vesa.c b/tools/kvm/hw/vesa.c
index 6ab07ee..9315510 100644
---
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/ioport.h |2 --
tools/kvm/virtio/9p.c | 12 +++-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/tools/kvm/include/kvm/ioport.h b/tools/kvm/include/kvm/ioport.h
index
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/ioport.h |2 --
tools/kvm/virtio/console.c | 11 +++
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/tools/kvm/include/kvm/ioport.h b/tools/kvm/include/kvm/ioport.h
index a6bcc6a..0c68e8c
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/ioport.h |3 ---
tools/kvm/virtio/net.c | 12
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/tools/kvm/include/kvm/ioport.h b/tools/kvm/include/kvm/ioport.h
index
Since multiple hardware rng devices of the same type are currently
unsupported by the kernel, this serves more as an example of a basic
virtio driver under kvm tools and can be used to debug the PCI layer.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/ioport.h
On 05/25/2011 09:49 AM, Markus Schade wrote:
Git bisect tells me that this is the first bad commit:
-%-
aff48baa34c033318ad322ecbf2e4bcd891b29ca is the first bad commit
commit aff48baa34c033318ad322ecbf2e4bcd891b29ca
Author: Avi Kivity a...@redhat.com
Date: Sun
On Thu, May 26, 2011 at 09:31:50AM +0300, Avi Kivity wrote:
On 05/25/2011 09:18 PM, Marcelo Tosatti wrote:
Commit fa4491a6b667304 moved the permission check for io instructions
to the -check_perm callback. It failed to copy the port value from RDX
register for string and in,out ax,dx
On 05/26/2011 09:55 AM, Gleb Natapov wrote:
+ case SrcDX:
+ c-src.type = OP_REG;
+ c-src.bytes = c-op_bytes;
Needs to be 2. Otherwise we'll see extra bits from edx, or lose
bits from dx if it's a 1-byte instruction.
But those extra bits will be dropped
On 05/26/2011 10:02 AM, Avi Kivity wrote:
Can
c-op_bytes ever be 1?
in %dx, %al
er, that doesn't change op_bytes. Still, op_bytes is irrelevant for
SrcDX, the 16-bit version is always used.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to
On Thu, May 26, 2011 at 10:04:24AM +0300, Avi Kivity wrote:
On 05/26/2011 10:02 AM, Avi Kivity wrote:
Can
c-op_bytes ever be 1?
in %dx, %al
er, that doesn't change op_bytes.
Yep.
Still, op_bytes is irrelevant for
SrcDX, the 16-bit version is
On 05/26/2011 09:07 AM, Gleb Natapov wrote:
Still, op_bytes is irrelevant for
SrcDX, the 16-bit version is always used.
If SrcDX/DstDX will be used only for decoding in/out instruction
then yes. Otherwise it is nice to have more general decoder.
Not counting instructions that read/write
Am 25.05.2011 22:34, schrieb Josh Durgin:
Signed-off-by: Josh Durgin josh.dur...@dreamhost.com
---
block/rbd.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/block/rbd.c b/block/rbd.c
index a44d160..b95b1eb 100644
--- a/block/rbd.c
+++
Am 25.05.2011 22:34, schrieb Josh Durgin:
The new format is
rbd:pool/image[@snapshot][:option1=value1[:option2=value2...]]
Each option is used to configure rados, and may be any Ceph option, or conf.
The conf option specifies a Ceph configuration file to read.
This allows rbd volumes from
On 05/25/2011 05:09 AM, Takuya Yoshikawa wrote:
From: Takuya Yoshikawayoshikawa.tak...@oss.ntt.co.jp
During tracing the emulator, we noticed that init_emulate_ctxt()
sometimes took a bit longer time than we expected.
This patch is for mitigating the problem by some degree.
By looking into the
On Thu, May 26, 2011 at 11:19:03AM +0300, Avi Kivity wrote:
On 05/25/2011 05:09 AM, Takuya Yoshikawa wrote:
From: Takuya Yoshikawayoshikawa.tak...@oss.ntt.co.jp
During tracing the emulator, we noticed that init_emulate_ctxt()
sometimes took a bit longer time than we expected.
This patch
On Thu, May 26, 2011 at 09:49:21AM +0200, Paolo Bonzini wrote:
On 05/26/2011 09:07 AM, Gleb Natapov wrote:
Still, op_bytes is irrelevant for
SrcDX, the 16-bit version is always used.
If SrcDX/DstDX will be used only for decoding in/out instruction
then yes. Otherwise it is nice to have
On 05/20/2011 08:12 PM, Jan Kiszka wrote:
This is a rather short round as the next and final one cannot be split
up very well.
We start with three code cleanup patches, then work towards using
upstream kvm_cpu_exec, and finally rework the core's PIO access
management used for device assignment.
On Wed, May 25, 2011 at 03:49:40PM -0700, Shirley Ma wrote:
On Fri, 2011-05-20 at 02:41 +0300, Michael S. Tsirkin wrote:
So the requirements are
- data must be released in a timely fashion (e.g. unlike virtio-net
tun or bridge)
The current patch doesn't enable tun zero-copy. tun will
On Thu, 2011-05-26 at 09:42 +0300, Sasha Levin wrote:
Allow specifying an optional parameter when registering an
ioport range. The callback functions provided by the registering
module will be called with the same parameter.
This may be used to keep context during callbacks on IO operations.
On Thu, 2011-05-26 at 11:53 +0300, Pekka Enberg wrote:
On Thu, 2011-05-26 at 09:42 +0300, Sasha Levin wrote:
Allow specifying an optional parameter when registering an
ioport range. The callback functions provided by the registering
module will be called with the same parameter.
This
On Thu, May 26, 2011 at 12:02 PM, Sasha Levin levinsasha...@gmail.com wrote:
On Thu, 2011-05-26 at 11:53 +0300, Pekka Enberg wrote:
On Thu, 2011-05-26 at 09:42 +0300, Sasha Levin wrote:
Allow specifying an optional parameter when registering an
ioport range. The callback functions provided
On 05/26/2011 10:26 AM, Gleb Natapov wrote:
Why would c-dst.bytes != c-src.bytes for cwd/cdq/cqo if we'll set
c-dst.bytes to op_bytes during decode?
Duh, you're right, cwd/cdq/cqo uses SrcAcc which has
c-src.bytes = (c-d ByteOp) ? 1 : c-op_bytes;
so in practice c-src.bytes =
On Thu, 2011-05-26 at 12:04 +0300, Pekka Enberg wrote:
On Thu, May 26, 2011 at 12:02 PM, Sasha Levin levinsasha...@gmail.com wrote:
On Thu, 2011-05-26 at 11:53 +0300, Pekka Enberg wrote:
On Thu, 2011-05-26 at 09:42 +0300, Sasha Levin wrote:
Allow specifying an optional parameter when
On Thu, May 26, 2011 at 12:14 PM, Sasha Levin levinsasha...@gmail.com wrote:
I've wanted to keep the original interface clean, Most of the IO port
users don't (and probably won't) require a parameter.
Well now struct ioport_operations isn't very clean is it - or the code
that needs to
On 05/26/2011 11:02 AM, Gleb Natapov wrote:
We can make it honor ByteOp. There will be no instruction that will
specify DstDX | ByteOp though.
in %dx, %al and out %al, %dx will via D2bv.
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On Thu, May 26, 2011 at 11:23:44AM +0200, Paolo Bonzini wrote:
On 05/26/2011 11:02 AM, Gleb Natapov wrote:
We can make it honor ByteOp. There will be no instruction that will
specify DstDX | ByteOp though.
in %dx, %al and out %al, %dx will via D2bv.
Yeah. Should ignore ByteOp then.
--
On Thu, 2011-05-26 at 12:20 +0300, Pekka Enberg wrote:
On Thu, May 26, 2011 at 12:14 PM, Sasha Levin levinsasha...@gmail.com wrote:
I've wanted to keep the original interface clean, Most of the IO port
users don't (and probably won't) require a parameter.
Well now struct
On Thu, May 26, 2011 at 12:38 PM, Sasha Levin levinsasha...@gmail.com wrote:
One option here is to rename 'struct ioport_entry' to 'struct ioport'
and pass a pointer to that as the first argument to all of the ops.
That's what most APIs in the kernel do anyway.
Why do it like that? this way
Hi Sasha,
On Thu, May 26, 2011 at 12:38 PM, Sasha Levin levinsasha...@gmail.com wrote:
One option here is to rename 'struct ioport_entry' to 'struct ioport'
and pass a pointer to that as the first argument to all of the ops.
That's what most APIs in the kernel do anyway.
Why do it like that?
On Thu, May 26, 2011 at 11:00:24AM +0200, Paolo Bonzini wrote:
On 05/26/2011 10:26 AM, Gleb Natapov wrote:
Why would c-dst.bytes != c-src.bytes for cwd/cdq/cqo if we'll set
c-dst.bytes to op_bytes during decode?
Duh, you're right, cwd/cdq/cqo uses SrcAcc which has
Hello,
after I tried updating our production host to 0.14.0 or 0.14.1, our windows
terminal server stopped booting.
Here's BSOD screen:
http://nik.lbox.cz/public/wincrash.png
reverting to 0.13.5 fixes the problem.
I can't reproduce this on testing hardware though :(
exact guest version:
On Thu, May 26, 2011 at 11:59:10AM +0200, Nikola Ciprich wrote:
Hello,
after I tried updating our production host to 0.14.0 or 0.14.1, our windows
terminal server stopped booting.
Here's BSOD screen:
http://nik.lbox.cz/public/wincrash.png
reverting to 0.13.5 fixes the problem.
I can't
Hello Gleb!
What is you command line?
currently it's:
/usr/bin/qemu-kvm -S -M pc-0.13 -enable-kvm -m 4096 -smp
1,sockets=1,cores=1,threads=1 -name vmwts02 -uuid
1e501300-dc48-11df-a690-00304834195b -nodefconfig -nodefaults -chardev
On Thu, May 26, 2011 at 12:20:56PM +0200, Nikola Ciprich wrote:
You can make a copy from your production image, install 0.14 version in
different place from 0.13 and experiment.
yup, I think I've tried it also with exact copy and wasn't able to reproduce
it, but I'll try it again and report
Allow specifying an optional parameter when registering an
ioport range. The callback functions provided by the registering
module will be called with the same parameter.
This may be used to keep context during callbacks on IO operations.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
Add a very simple allocation of ioports.
This prevents the need to coordinate ioports between different
modules.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/ioport.h |7 ++-
tools/kvm/ioport.c | 24 +++-
2 files changed,
Since ioports now has the ability to pass context to its
callbacks, we can implement multiple blk devices more efficiently.
We can get a ptr to the 'current' blk dev on each ioport call, which
means that we don't need to keep track of the blk device allocation
and ioport distribution within the
Since multiple hardware rng devices of the same type are currently
unsupported by the kernel, this serves more as an example of a basic
virtio driver under kvm tools and can be used to debug the PCI layer.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/ioport.h
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/ioport.h |2 --
tools/kvm/virtio/9p.c | 12 +++-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/tools/kvm/include/kvm/ioport.h b/tools/kvm/include/kvm/ioport.h
index
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/hw/vesa.c|7 +++
tools/kvm/include/kvm/ioport.h |2 --
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/tools/kvm/hw/vesa.c b/tools/kvm/hw/vesa.c
index ec4788c..85fe1a9 100644
---
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/ioport.h |3 ---
tools/kvm/virtio/net.c | 12
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/tools/kvm/include/kvm/ioport.h b/tools/kvm/include/kvm/ioport.h
index
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/ioport.h |2 --
tools/kvm/virtio/console.c | 11 +++
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/tools/kvm/include/kvm/ioport.h b/tools/kvm/include/kvm/ioport.h
index 310f75d..4fccbd6
On 05/20/2011 05:56 AM, Luke-Jr wrote:
Finally decided to see just how much of the Radeon was working (eg, if it was
*just* OpenCL or not), and I am happy to confirm that both video output and
OpenGL acceleration are fully functional inside KVM.
That's really surprising (and a really good
On Thu, May 26, 2011 at 09:49:21AM +0200, Paolo Bonzini wrote:
On 05/26/2011 09:07 AM, Gleb Natapov wrote:
Still, op_bytes is irrelevant for
SrcDX, the 16-bit version is always used.
If SrcDX/DstDX will be used only for decoding in/out instruction
then yes. Otherwise it is nice to have
OK, I tried copying the whole image to my test box running 0.14.0 again and it
crashes with exactly the same BSOD!
So now I have the test environment to play with...
What should I check/try now?
n.
PS: I'm not sure what You mean by permissions, but I'm using LVM partitions and
qemu-kvm is
On Thu, May 26, 2011 at 01:50:35PM +0200, Nikola Ciprich wrote:
OK, I tried copying the whole image to my test box running 0.14.0 again and
it crashes with exactly the same BSOD!
So now I have the test environment to play with...
What should I check/try now?
n.
PS: I'm not sure what You
Commit fa4491a6b667304 moved the permission check for io instructions
to the -check_perm callback. It failed to copy the port value from RDX
register for string and in,out ax,dx instructions.
Fix it by reading RDX register at decode stage when appropriate.
Fixes FC8.32 installation.
diff --git
This BSOD usually indicates that Windows can't write to the boot disk.
This is usually happens if qemu has no permission to write to the image
file. But if you are starting qemu as a root this is probably is not the
OK, I see.
case. So what is your 0.14 command line?
here it goes:
On 05/26/2011 08:44 AM, Avi Kivity wrote:
On 05/25/2011 09:49 AM, Markus Schade wrote:
Git bisect tells me that this is the first bad commit:
-%-
aff48baa34c033318ad322ecbf2e4bcd891b29ca is the first bad commit
commit aff48baa34c033318ad322ecbf2e4bcd891b29ca
On Thu, May 26, 2011 at 02:03:57PM +0200, Nikola Ciprich wrote:
This BSOD usually indicates that Windows can't write to the boot disk.
This is usually happens if qemu has no permission to write to the image
file. But if you are starting qemu as a root this is probably is not the
OK, I see.
May be libvirt does something funny with selinux.
it shouldn't, I don't have selinux enabled in host kernel at all..
Try to run with -M pc-0.13.
tried now, same result...
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
On Thu, May 26, 2011 at 02:30:00PM +0200, Nikola Ciprich wrote:
May be libvirt does something funny with selinux.
it shouldn't, I don't have selinux enabled in host kernel at all..
Try to run with -M pc-0.13.
tried now, same result...
Hmm. And what if you start qemu directly (without
Hmm. And what if you start qemu directly (without using libvirt) with 0.13
command line?
/usr/bin/qemu-kvm -M pc-0.13 -enable-kvm -m 4096 -boot c -drive
file=/dev/vgshared/vmtst04-1,if=none,id=drive-ide0-0-0,format=raw -device
ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -vnc
On Thu, May 26, 2011 at 02:46:30PM +0200, Nikola Ciprich wrote:
Hmm. And what if you start qemu directly (without using libvirt) with 0.13
command line?
/usr/bin/qemu-kvm -M pc-0.13 -enable-kvm -m 4096 -boot c -drive
file=/dev/vgshared/vmtst04-1,if=none,id=drive-ide0-0-0,format=raw -device
Should be more like that one with correct image path:
huh, now I got a bit lost :)
I tried running both:
/usr/bin/qemu-kvm -M pc-0.13 -enable-kvm -m 4096 -smp
1,sockets=1,cores=1,threads=1 -name vmtst04 -uuid
1f8328b8-8849-11e0-91e9-00259009d78c -nodefconfig -nodefaults -chardev
socket,id=char
There is no ntpdate.rpm in RHEL-5, ntp.rpm has /usr/sbin/ntpdate.
---
client/tests/kvm/unattended/RHEL-5-series.ks |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/client/tests/kvm/unattended/RHEL-5-series.ks
b/client/tests/kvm/unattended/RHEL-5-series.ks
index
Hi,
Started playing around with autotest. For starters tried to run the
basic install, boot + shutdown tests for a bunch of guests I have iso
images laying around here, expecting that working out-of-the-box.
Unfortunaly that wasn't the case. RHEL 5.any does't install. Fixed.
OpenSUSE 11.1
On Thu, May 26, 2011 at 02:56:40PM +0200, Nikola Ciprich wrote:
Should be more like that one with correct image path:
huh, now I got a bit lost :)
I tried running both:
/usr/bin/qemu-kvm -M pc-0.13 -enable-kvm -m 4096 -smp
1,sockets=1,cores=1,threads=1 -name vmtst04 -uuid
No, try to run the one I gave you. Just replace the image file path. I
do no have much hope it will work though, but worth trying.
OK, I tried, I just had to remove the monitor device. Still, it fails the same
way...
n.
--
Gleb.
--
To unsubscribe from this list:
On Thu, May 26, 2011 at 03:15:19PM +0200, Nikola Ciprich wrote:
No, try to run the one I gave you. Just replace the image file path. I
do no have much hope it will work though, but worth trying.
OK, I tried, I just had to remove the monitor device. Still, it fails the
same way...
According
This patchset enables a new CPU feature SMEP (Supervisor Mode Execution
Protection) in KVM. SMEP prevents kernel from executing code in application.
Updated Intel SDM describes this CPU feature. The document will be published
soon.
This patchset is based on Fenghua's SMEP patch series, as
This patchset enables a new CPU feature SMEP (Supervisor Mode Execution
Protection) in QEMU-KVM. SMEP prevents kernel from executing code in
application.
Updated Intel SDM describes this CPU feature. The document will be published
soon.
SMEP is identified by CPUID leaf 7 EBX[7], which is 0
According to this:
http://social.msdn.microsoft.com/Forums/en-US/embeddedwindowscomponents/thread/09aae527-ff6d-4003-9e59-962d73d409ed
such bsod happens because Windows can't access boot device. Your boot
device is IDE. Nothing changed in this area from 13 to 14. Are you sure
your image was
Use values calculated and assigned to local variables instead
of ignoring them.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/kvm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/kvm/kvm.c b/tools/kvm/kvm.c
index 7284211..1d756e0 100644
---
Currently the VCPU loop would exit when the thread received any signal.
Change behaviour to exit only when SIGKVMEXIT is received. This change
prevents from the guest to terminate when unrelated signals are processed
by the thread (for example, when attaching a debugger).
Signed-off-by: Sasha
Makes IRQ allocation for new devices thread-safe.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/irq.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/tools/kvm/irq.c b/tools/kvm/irq.c
index 15f4702..f92123d 100644
---
Make MMIO code thread-safe.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/mmio.c | 24 +---
1 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/tools/kvm/mmio.c b/tools/kvm/mmio.c
index ef986bf..59512c3 100644
--- a/tools/kvm/mmio.c
+++
Adds a rwlock wrapper which like the mutex wrapper makes rwlock calls
similar to their kernel counterparts.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/include/kvm/rwsem.h | 39 +++
1 files changed, 39 insertions(+), 0 deletions(-)
Makes ioport thread-safe.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/ioport.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/tools/kvm/ioport.c b/tools/kvm/ioport.c
index 1f13960..db9ff0f 100644
--- a/tools/kvm/ioport.c
+++
On 05/18/2011 02:05 AM, Sasha Levin wrote:
On Tue, 2011-05-17 at 20:18 -0500, Eric Van Hensbergen wrote:
On Tue, May 17, 2011 at 3:27 PM, Sasha Levinlevinsasha...@gmail.com wrote:
On Tue, 2011-05-17 at 22:08 +0300, Sasha Levin wrote:
'kvm_9p' isn't created as a device under /dev, it's just a
On Thu, 2011-05-26 at 07:28 -0700, Venkateswararao Jujjuri wrote:
Any progress on this? May I get more detailed instructions on how
you did this trick? Basically booting on 9P/VirtIO.
Thanks,
JV
Ofcourse. This change didn't go into tools/kvm/ since we only support
the legacy 9p2000
On Thu, May 26, 2011 at 03:32:43PM +0200, Nikola Ciprich wrote:
According to this:
http://social.msdn.microsoft.com/Forums/en-US/embeddedwindowscomponents/thread/09aae527-ff6d-4003-9e59-962d73d409ed
such bsod happens because Windows can't access boot device. Your boot
device is IDE.
On 05/26/2011 01:28 PM, Markus Schade wrote:
On 05/26/2011 08:44 AM, Avi Kivity wrote:
On 05/25/2011 09:49 AM, Markus Schade wrote:
Git bisect tells me that this is the first bad commit:
-%-
aff48baa34c033318ad322ecbf2e4bcd891b29ca is the first bad commit
On 05/26/2011 07:36 AM, Sasha Levin wrote:
On Thu, 2011-05-26 at 07:28 -0700, Venkateswararao Jujjuri wrote:
Any progress on this? May I get more detailed instructions on how
you did this trick? Basically booting on 9P/VirtIO.
Thanks,
JV
Ofcourse. This change didn't go into tools/kvm/ since
On Thu, May 26, 2011 at 05:20:32PM +0200, Markus Schade wrote:
On 05/26/2011 01:28 PM, Markus Schade wrote:
On 05/26/2011 08:44 AM, Avi Kivity wrote:
On 05/25/2011 09:49 AM, Markus Schade wrote:
Git bisect tells me that this is the first bad commit:
-%-
On Thu, 2011-05-26 at 11:49 +0300, Michael S. Tsirkin wrote:
On Wed, May 25, 2011 at 03:49:40PM -0700, Shirley Ma wrote:
On Fri, 2011-05-20 at 02:41 +0300, Michael S. Tsirkin wrote:
So the requirements are
- data must be released in a timely fashion (e.g. unlike
virtio-net
tun or
Michael S. Tsirkin m...@redhat.com wrote on 05/20/2011 04:40:07 AM:
OK, here is the large patchset that implements the virtio spec update
that I sent earlier (the spec itself needs a minor update, will send
that out too next week, but I think we are on the same page here
already). It
On Thu, 2011-05-26 at 08:22 -0700, Venkateswararao Jujjuri wrote:
On 05/26/2011 07:36 AM, Sasha Levin wrote:
On Thu, 2011-05-26 at 07:28 -0700, Venkateswararao Jujjuri wrote:
Any progress on this? May I get more detailed instructions on how
you did this trick? Basically booting on
On Thu, 26 May 2011, Sasha Levin wrote:
Makes ioport thread-safe.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/ioport.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/tools/kvm/ioport.c b/tools/kvm/ioport.c
index 1f13960..db9ff0f 100644
---
On Thu, 26 May 2011, Sasha Levin wrote:
Adds a rwlock wrapper which like the mutex wrapper makes rwlock calls
similar to their kernel counterparts.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
There's no explanation why a mutex isn't sufficient. The pthread locking
primitives aren't
Shirley Ma x...@us.ibm.com wrote on 05/26/2011 09:12:22 PM:
Could you please try TCP_RRs as well?
Right. Here's the result for TCP_RR:
__
# RR% SD% CPU%
__
1 4.5 -31.4-27.9
2 5.1 -9.7
On Thu, 2011-05-26 at 19:02 +0300, Pekka Enberg wrote:
On Thu, 26 May 2011, Sasha Levin wrote:
Adds a rwlock wrapper which like the mutex wrapper makes rwlock calls
similar to their kernel counterparts.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
There's no explanation why a
On Thu, 2011-05-26 at 19:01 +0300, Pekka Enberg wrote:
On Thu, 26 May 2011, Sasha Levin wrote:
Makes ioport thread-safe.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
tools/kvm/ioport.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git
Krishna Kumar2/India/IBM wrote on 05/26/2011 09:51:32 PM:
Could you please try TCP_RRs as well?
Right. Here's the result for TCP_RR:
The actual transaction rate/second numbers are:
_
# RR1 RR2 (%) SD1SD2
* Sasha Levin levinsasha...@gmail.com wrote:
On Thu, 2011-05-26 at 19:02 +0300, Pekka Enberg wrote:
On Thu, 26 May 2011, Sasha Levin wrote:
Adds a rwlock wrapper which like the mutex wrapper makes rwlock calls
similar to their kernel counterparts.
Signed-off-by: Sasha Levin
On 05/26/2011 09:05 PM, Ingo Molnar wrote:
I've added some rwlocks because of what Ingo said yesterday about
adding/removing devices after the first initialization phase.
Take MMIO lock for example: Since we can now run SMP guests, we may
have multiple MMIO exits (one from each VCPU
On Thu, May 26, 2011 at 9:11 PM, Avi Kivity a...@redhat.com wrote:
On 05/26/2011 09:05 PM, Ingo Molnar wrote:
I've added some rwlocks because of what Ingo said yesterday about
adding/removing devices after the first initialization phase.
Take MMIO lock for example: Since we can now
In this case I am very puzzled :)
well, so am I :)
but at least, I now know there seems to be problem with disk access. I'll ask
some of our windows guys to try some failsave mode or something and find out
what is going on...
I'll report when I know something.
thanks for Your help!
n.
--
On Thu, 2011-05-26 at 21:21 +0300, Pekka Enberg wrote:
On Thu, May 26, 2011 at 9:11 PM, Avi Kivity a...@redhat.com wrote:
On 05/26/2011 09:05 PM, Ingo Molnar wrote:
I've added some rwlocks because of what Ingo said yesterday about
adding/removing devices after the first
Hi Avi,
I'm working on adding ioeventfd support into tools/kvm/.
Currently the implementation creates ioeventfd entries at the
'VIRTIO_PCI_QUEUE_NOTIFY' of each device and waits on all of them using
epoll().
The basics are working - when IO is triggered I receive a notification
using the event
On Thu, 2011-05-26 at 11:49 +0300, Michael S. Tsirkin wrote:
- SG support
- HIGHDMA support (on arches where this makes sense)
This can be checked by device flags.
OK, but pls note that SG can get turned off dynamically.
Tested the patch w/i SG dynmically on/off and tcpdump
This patchset add supports for TX zero-copy between guest and host
kernel through vhost. It significantly reduces CPU utilization on the
local host on which the guest is located (It reduced about 50% CPU usage
for single stream test on the host, while 4K message size BW has
increased about 50%).
Signed-off-by: Shirley Ma x...@us.ibm.com
---
include/net/sock.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 01810a3..ab09097 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -562,6 +562,7 @@ enum sock_flags {
This patch adds userspace buffers support in skb shared info. A new
struct skb_ubuf_info is needed to maintain the userspace buffers
argument and index, a callback is used to notify userspace to release
the buffers once lower device has done DMA (Last reference to that skb
has gone).
If there is
Only when buffer size is greater than GOODCOPY_LEN (256), macvtap
enables zero-copy.
Signed-off-by: Shirley Ma x...@us.ibm.com
---
drivers/net/macvtap.c | 132
1 files changed, 121 insertions(+), 11 deletions(-)
diff --git
Hello Michael,
Let me anything I might miss from your preview's review.
Thanks
Shirley
---
This patch maintains the outstanding userspace buffers in the
sequence it is delivered to vhost. The outstanding userspace buffers
will be marked as done once the lower device buffers DMA has
1 - 100 of 130 matches
Mail list logo
