المركز الأمريكي للبحوث
A.R.C.
Tel : ( 00202 ) 25082727 - 2508884183
Fax No : ( 00202 ) 25082727
E-MAIL: new.a...@ymail .com
محمول : 162494849 - 0020
السيد / وكيل الجامعة لشئون المكتبات
يسر المركز بعرض الدراسات العلمية التطبيقية للمواضيع التالية
التصميم الهندسي
تطور نظم
On 08/03/2010 02:36 AM, Anthony Liguori wrote:
On 08/02/2010 05:42 PM, Andre Przywara wrote:
Anthony Liguori wrote:
On 08/02/2010 08:49 AM, Ulrich Drepper wrote:
glibc uses the cache size information returned by cpuid to perform
optimizations. For instance, copy operations which would pollute
On 08/02/2010 11:50 PM, Stefan Hajnoczi wrote:
On Mon, Aug 2, 2010 at 6:46 PM, Anthony Liguorianth...@codemonkey.ws wrote:
On 08/02/2010 12:15 PM, John Leach wrote:
Hi,
I've come across a problem with read and write disk IO performance when
using O_DIRECT from within a kvm guest. With
On 08/03/2010 05:30 AM, Lai Jiangshan wrote:
This patch is just a big cleanup. it reduces 220 lines of code.
It introduces sibling_pte array for tracking identical sptes, so the
identical sptes can be linked as a single linked list by their
corresponding sibling_pte. A reverse map or a
On 08/02/2010 06:20 PM, Jeremy Fitzhardinge wrote:
On 08/02/2010 01:48 AM, Avi Kivity wrote:
On 07/26/2010 09:15 AM, Srivatsa Vaddagiri wrote:
Paravirtual spinlock implementation for KVM guests, based heavily on
Xen guest's
spinlock implementation.
+
+static struct spinlock_stats
+{
+
On (Thu) Jul 29 2010 [16:17:48], Nirmal Guhan wrote:
Hi,
I run Fedora 12 and guest is also Fedora 12. I use br0/tap0 for
networking and communicate between host-guest using socket. I do
see some references to virtio, pci based ipc and inter-vm shared
memory but they are not current. My
On 08/02/2010 11:33 PM, Joerg Roedel wrote:
On Mon, Aug 02, 2010 at 06:18:09PM +0300, Avi Kivity wrote:
On 08/02/2010 05:46 PM, Joerg Roedel wrote:
This patch lets the nested vmrun fail if the L1 hypervisor
has not intercepted vmrun. This fixes the vmrun intercept
check unit test.
+
Linus, please pull from
git://git.kernel.org/pub/scm/virt/kvm/kvm.git kvm-updates/2.6.36
to receive the KVM updates for the 2.6.36 cycle. No major features:
mostly improved mmu and emulator correctness, some performance
improvements, and support for guest XSAVE and AVX.
Alex Williamson
-Original Message-
From: Shirley Ma [mailto:mashi...@us.ibm.com]
Sent: Friday, July 30, 2010 6:31 AM
To: Xin, Xiaohui
Cc: net...@vger.kernel.org; kvm@vger.kernel.org; linux-ker...@vger.kernel.org;
m...@redhat.com; mi...@elte.hu; da...@davemloft.net;
herb...@gondor.apana.org.au;
On 08/03/2010 02:51 PM, Avi Kivity wrote:
On 08/03/2010 05:30 AM, Lai Jiangshan wrote:
This patch is just a big cleanup. it reduces 220 lines of code.
It introduces sibling_pte array for tracking identical sptes, so the
identical sptes can be linked as a single linked list by their
Zheng, Shaohui wrote:
In our experiences, windows 2008 datacenter is the only version to
support CPU hotplug, and we did not find any official announce for
other windows, so we tested windows 2008 data center only.
Thanks for Kevin pointing out it, we will try windows7 hotplug
feature.
The kvm unit tests, previously found in qemu-kvm.git's kvm/test/
directory, have been moved to their own repository, kvm-unit-tests.git.
The repository URL is
git://git.kernel.org/pub/scm/virt/kvm/kvm-unit-tests.git; more
information can be found in
' % extra_params
Not quite:
08/03 13:57:04 DEBUG|kvm_vm:0637| Running qemu command:
/root/autotest/client/tests/kvm/qemu -name 'vm1' -monitor
unix:'/tmp/monitor-humanmonitor1-20100803-135522-SqL2',server,nowait
-serial unix:'/tmp/serial-20100803-135522-SqL2',server,nowait -m 512
-kernel
')
+params['extra_params'] += ' %s' % extra_params
Not quite:
08/03 13:57:04 DEBUG|kvm_vm:0637| Running qemu command:
/root/autotest/client/tests/kvm/qemu -name 'vm1' -monitor
unix:'/tmp/monitor-humanmonitor1-20100803-135522-SqL2',server,nowait
-serial unix:'/tmp/serial-20100803
On Tue, Aug 03, 2010 at 02:33:02PM +0300, Gleb Natapov wrote:
On Tue, Aug 03, 2010 at 12:13:06PM +0100, Richard W.M. Jones wrote:
qemu compiled from today's git. Using the following command line:
$qemudir/x86_64-softmmu/qemu-system-x86_64 -L $qemudir/pc-bios \
-drive
On Tue, Jul 06, 2010, Dong, Eddie wrote about RE: [PATCH 9/24] Implement
VMCLEAR:
Nadav Har'El wrote:
This patch implements the VMCLEAR instruction.
...
SDM implements alignment check, range check and reserve bit check and may
generate VMfail(VMCLEAR with invalid physical address).
As well
On Tue, Aug 03, 2010 at 01:10:00PM +0100, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 02:33:02PM +0300, Gleb Natapov wrote:
On Tue, Aug 03, 2010 at 12:13:06PM +0100, Richard W.M. Jones wrote:
qemu compiled from today's git. Using the following command line:
On Tue, Aug 03, 2010 at 03:37:14PM +0300, Gleb Natapov wrote:
On Tue, Aug 03, 2010 at 01:10:00PM +0100, Richard W.M. Jones wrote:
I can't see anything about this in the kernel changelog. Can you
point me to the commit or the key phrase to look for?
7972995b0c346de76
Thanks - I see.
On Tue, 03 Aug 2010 01:46:01 +0200
Juan Quintela quint...@redhat.com wrote:
Please send in any agenda items you are interested in covering.
- 0.13
Let's keep remembering Anthony ;-)
thanks,
Juan
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
On 08/03/2010 04:01 PM, Luiz Capitulino wrote:
On Tue, 03 Aug 2010 01:46:01 +0200
Juan Quintelaquint...@redhat.com wrote:
Please send in any agenda items you are interested in covering.
- 0.13
More specifically, 0.13-rc0. Tagged but not announced? I'd like to
announce it so people can
On 08/03/2010 03:48 PM, Richard W.M. Jones wrote:
Thanks for the explanation. I'll repost my DMA-like fw-cfg patch
once I've rebased it and done some more testing. This huge regression
for a common operation (implementing -initrd) needs to be solved
without using inb/rep ins.
Adding more
On 08/03/2010 08:16 AM, Avi Kivity wrote:
On 08/03/2010 04:01 PM, Luiz Capitulino wrote:
On Tue, 03 Aug 2010 01:46:01 +0200
Juan Quintelaquint...@redhat.com wrote:
Please send in any agenda items you are interested in covering.
- 0.13
More specifically, 0.13-rc0. Tagged but not
This is the sequel of the previous fix on the unittest
subtest: As we're running on a loop through the
unittest list, the original extra_params need to be
restored at the end of each test, so previously
set extra_params don't leak to other unittests.
Signed-off-by: Lucas Meneghel Rodrigues
On 08/03/2010 04:31 PM, Anthony Liguori wrote:
On 08/03/2010 08:16 AM, Avi Kivity wrote:
On 08/03/2010 04:01 PM, Luiz Capitulino wrote:
On Tue, 03 Aug 2010 01:46:01 +0200
Juan Quintelaquint...@redhat.com wrote:
Please send in any agenda items you are interested in covering.
- 0.13
More
On Tue, Aug 03, 2010 at 04:19:39PM +0300, Avi Kivity wrote:
On 08/03/2010 03:48 PM, Richard W.M. Jones wrote:
Thanks for the explanation. I'll repost my DMA-like fw-cfg patch
once I've rebased it and done some more testing. This huge regression
for a common operation (implementing
On 08/03/2010 08:49 AM, Avi Kivity wrote:
On 08/03/2010 04:31 PM, Anthony Liguori wrote:
On 08/03/2010 08:16 AM, Avi Kivity wrote:
On 08/03/2010 04:01 PM, Luiz Capitulino wrote:
On Tue, 03 Aug 2010 01:46:01 +0200
Juan Quintelaquint...@redhat.com wrote:
Please send in any agenda items you
On 08/03/2010 05:25 PM, Anthony Liguori wrote:
I meant users. Many users avoid git and test tarballs which come
from an announcement instead. Same for distros, things like rawhide
can package an -rc0.
-rc0 is available in rawhide FWIW.
Cool.
--
error compiling committee.c: too many
On 08/03/2010 05:05 PM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 04:19:39PM +0300, Avi Kivity wrote:
On 08/03/2010 03:48 PM, Richard W.M. Jones wrote:
Thanks for the explanation. I'll repost my DMA-like fw-cfg patch
once I've rebased it and done some more testing. This huge
On Mon, 2010-08-02 at 21:50 +0100, Stefan Hajnoczi wrote:
On Mon, Aug 2, 2010 at 6:46 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 08/02/2010 12:15 PM, John Leach wrote:
Hi,
I've come across a problem with read and write disk IO performance when
using O_DIRECT from within a kvm
On 08/03/2010 05:40 PM, John Leach wrote:
dd if=/dev/mapper/zero of=/dev/null bs=8k count=100 iflag=direct
819200 bytes (8.2 GB) copied, 3.46529 s, 2.4 GB/s
dd if=/dev/mapper/zero of=/dev/null bs=8k count=100
819200 bytes (8.2 GB) copied, 5.5741 s, 1.5 GB/s
dd is just using
On 08/03/2010 12:28 PM, Tvrtko Ursulin wrote:
I have basically built 2.6.35 with make oldconfig from a working 2.6.34.
Latter works fine in kvm while 2.6.35 hangs very early. I see nothing after
grub (have early printk and verbose bootup enabled), just a blinking VGA
cursor and CPU at 100%.
On Tue, 2010-08-03 at 09:35 +0300, Dor Laor wrote:
On 08/02/2010 11:50 PM, Stefan Hajnoczi wrote:
On Mon, Aug 2, 2010 at 6:46 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
On 08/02/2010 12:15 PM, John Leach wrote:
Hi,
I've come across a problem with read and write disk IO
On Tue, Aug 03, 2010 at 05:38:25PM +0300, Avi Kivity wrote:
The time will only continue to grow as you add features and as the
distro bloats naturally.
Much better to create it once and only update it if some dependent
file changes (basically the current on-the-fly code + save a list of
On Tue, 2010-08-03 at 17:44 +0300, Avi Kivity wrote:
On 08/03/2010 05:40 PM, John Leach wrote:
dd if=/dev/mapper/zero of=/dev/null bs=8k count=100 iflag=direct
819200 bytes (8.2 GB) copied, 3.46529 s, 2.4 GB/s
dd if=/dev/mapper/zero of=/dev/null bs=8k count=100
819200
On Tuesday 03 Aug 2010 15:51:08 Avi Kivity wrote:
On 08/03/2010 12:28 PM, Tvrtko Ursulin wrote:
I have basically built 2.6.35 with make oldconfig from a working 2.6.34.
Latter works fine in kvm while 2.6.35 hangs very early. I see nothing
after grub (have early printk and verbose bootup
On Tuesday 03 Aug 2010 15:57:03 Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 15:51:08 Avi Kivity wrote:
On 08/03/2010 12:28 PM, Tvrtko Ursulin wrote:
I have basically built 2.6.35 with make oldconfig from a working
2.6.34. Latter works fine in kvm while 2.6.35 hangs very early. I see
On Tuesday 03 Aug 2010 16:17:20 Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 15:57:03 Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 15:51:08 Avi Kivity wrote:
On 08/03/2010 12:28 PM, Tvrtko Ursulin wrote:
I have basically built 2.6.35 with make oldconfig from a working
2.6.34.
IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.
The semantic match that finds this problem is as follows:
// smpl
@@
identifier x;
identifier request ~= pci_request.*|pci_resource.*;
@@
(
* x-irq
|
* x-resource
|
* request(x, ...)
On Tue, Aug 03, 2010 at 07:44:23PM +0400, Kulikov Vasiliy wrote:
IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.
The semantic match that finds this problem is as follows:
// smpl
@@
identifier x;
identifier request ~=
From: Tvrtko Ursulin tvrtko.ursu...@sophos.com
Date: Tue, Aug 03, 2010 at 11:31:02AM -0400
One interesting waning spotted:
include/config/auto.conf:555:warning: symbol value '-fcall-saved-ecx
-fcall- saved-edx' invalid for ARCH_HWEIGHT_CFLAGS
Copying Peter and Borislav, guys please
Hello Xiaohui,
On Tue, 2010-08-03 at 16:48 +0800, Xin, Xiaohui wrote:
May you share me with your performance results (including BW and
latency)on
vhost-net and how you get them(your configuration and especially with
the affinity
settings)?
My macvtap zero copy is incomplete, I am testing
On Tuesday 03 Aug 2010 16:17:20 Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 15:57:03 Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 15:51:08 Avi Kivity wrote:
On 08/03/2010 12:28 PM, Tvrtko Ursulin wrote:
I have basically built 2.6.35 with make oldconfig from a working
2.6.34.
On Tuesday 03 Aug 2010 16:49:01 Borislav Petkov wrote:
From: Tvrtko Ursulin tvrtko.ursu...@sophos.com
Date: Tue, Aug 03, 2010 at 11:31:02AM -0400
One interesting waning spotted:
include/config/auto.conf:555:warning: symbol value '-fcall-saved-ecx
-fcall- saved-edx' invalid for
On 08/03/2010 05:53 PM, Richard W.M. Jones wrote:
Total saving: 115ms.
815 ms by my arithmetic.
no, not true, 115ms.
If you bypass creating the initrd/cdrom (700 ms) and loading it (115ms)
you save 815ms.
You also save 3*N-2*P memory where N is the size of your initrd and
P is the
On 08/03/2010 05:57 PM, John Leach wrote:
On Tue, 2010-08-03 at 17:44 +0300, Avi Kivity wrote:
On 08/03/2010 05:40 PM, John Leach wrote:
dd if=/dev/mapper/zero of=/dev/null bs=8k count=100 iflag=direct
819200 bytes (8.2 GB) copied, 3.46529 s, 2.4 GB/s
dd if=/dev/mapper/zero
On Tue, Aug 03, 2010 at 07:10:18PM +0300, Avi Kivity wrote:
-kernel and -initrd is a developer's interface intended to make life
easier for users that use qemu to develop kernels. It was not
intended as a high performance DMA engine. Neither was the firmware
_configuration_ interface. That
On Sun, 1 Aug 2010 22:21:37 +0200
Alexander Graf ag...@suse.de wrote:
On 01.08.2010, at 16:02, Avi Kivity wrote:
Looks reasonable. Since it's fair to say I understand nothing about
powerpc, I'd like someone who does to review it and ack, please, with an
emphasis on the interfaces.
On 08/03/2010 09:53 AM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 05:38:25PM +0300, Avi Kivity wrote:
The time will only continue to grow as you add features and as the
distro bloats naturally.
Much better to create it once and only update it if some dependent
file changes
On 08/03/2010 07:28 PM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 07:10:18PM +0300, Avi Kivity wrote:
-kernel and -initrd is a developer's interface intended to make life
easier for users that use qemu to develop kernels. It was not
intended as a high performance DMA engine. Neither
On 08/03/2010 11:44 AM, Avi Kivity wrote:
On 08/03/2010 07:28 PM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 07:10:18PM +0300, Avi Kivity wrote:
-kernel and -initrd is a developer's interface intended to make life
easier for users that use qemu to develop kernels. It was not
intended
On 08/03/2010 07:44 PM, Avi Kivity wrote:
It's not a good path to follow. Tomorrow we'll need to load 300MB
initrds and we'll have to rework this yet again. Meanwhile the kernel
and virtio support demand loading of any image size you'd want to use.
Even better would be to use
On 08/03/2010 07:46 PM, Anthony Liguori wrote:
It doesn't appear to support live migration, or hiding the feature
for -M older.
It's not a good path to follow. Tomorrow we'll need to load 300MB
initrds and we'll have to rework this yet again. Meanwhile the
kernel and virtio support demand
On 08/03/2010 11:50 AM, Avi Kivity wrote:
On 08/03/2010 07:46 PM, Anthony Liguori wrote:
It doesn't appear to support live migration, or hiding the feature
for -M older.
It's not a good path to follow. Tomorrow we'll need to load 300MB
initrds and we'll have to rework this yet again.
On 08/03/2010 07:53 PM, Anthony Liguori wrote:
On 08/03/2010 11:50 AM, Avi Kivity wrote:
On 08/03/2010 07:46 PM, Anthony Liguori wrote:
It doesn't appear to support live migration, or hiding the feature
for -M older.
It's not a good path to follow. Tomorrow we'll need to load 300MB
On 08/03/2010 07:56 PM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 07:44:49PM +0300, Avi Kivity wrote:
On 08/03/2010 07:28 PM, Richard W.M. Jones wrote:
I have posted a small patch which makes this 650x faster without
appreciable complication.
It doesn't appear to support live
On 08/03/2010 11:50 AM, Avi Kivity wrote:
On 08/03/2010 07:46 PM, Anthony Liguori wrote:
It doesn't appear to support live migration, or hiding the feature
for -M older.
It's not a good path to follow. Tomorrow we'll need to load 300MB
initrds and we'll have to rework this yet again.
On Tue, Aug 03, 2010 at 07:44:49PM +0300, Avi Kivity wrote:
On 08/03/2010 07:28 PM, Richard W.M. Jones wrote:
I have posted a small patch which makes this 650x faster without
appreciable complication.
It doesn't appear to support live migration, or hiding the feature
for -M older.
AFAICT
On Tue, Aug 03, 2010 at 07:44:23PM +0400, Kulikov Vasiliy wrote:
IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.
The semantic match that finds this problem is as follows:
// smpl
@@
identifier x;
identifier request ~=
On 08/03/2010 12:01 PM, Avi Kivity wrote:
You mean, only one class of users cares about the performance of
loading an initrd. However, you've also argued in other threads how
important it is not to break libvirt even if it means we have to do
silly things (like change help text).
So... why
On 08/02/2010 11:59 PM, Avi Kivity wrote:
On 08/02/2010 06:20 PM, Jeremy Fitzhardinge wrote:
On 08/02/2010 01:48 AM, Avi Kivity wrote:
On 07/26/2010 09:15 AM, Srivatsa Vaddagiri wrote:
Paravirtual spinlock implementation for KVM guests, based heavily
on Xen guest's
spinlock
On 08/03/2010 08:42 PM, Anthony Liguori wrote:
However, I don't think we can objectively differentiate between a
major and minor user. Generally speaking, I would rather that we
not take the position of you are a minor user therefore we're not
going to accommodate you.
Again it's a matter
On Tue, Aug 03, 2010 at 08:58:10PM +0300, Avi Kivity wrote:
Richard, can you test kvm.git
master? it already contains one fix and we plan to add more.
Yup, I will ...
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog:
On 08/03/2010 12:58 PM, Avi Kivity wrote:
On 08/03/2010 08:42 PM, Anthony Liguori wrote:
However, I don't think we can objectively differentiate between a
major and minor user. Generally speaking, I would rather that we
not take the position of you are a minor user therefore we're not
going
Thanks. Will this work if the guest or host are different combo - for
instance ubuntu/debian or fedora/ubuntu? In other words, is there
anything generic other than using the sockets ? Am ok to use PCI to
communicate too if that can improve performance. Any pointers would be
helpful.
--Nirmal
On
On 08/03/2010 09:26 PM, Anthony Liguori wrote:
On 08/03/2010 12:58 PM, Avi Kivity wrote:
On 08/03/2010 08:42 PM, Anthony Liguori wrote:
However, I don't think we can objectively differentiate between a
major and minor user. Generally speaking, I would rather that
we not take the position
On 08/03/2010 09:43 PM, Avi Kivity wrote:
Really, the bar on new interfaces (both to guest and host) should be
high, much higher than it is now. Interfaces should be well
documented, future proof, migration safe, and orthogonal to existing
interfaces. While the first three points could be
On 08/03/2010 01:43 PM, Avi Kivity wrote:
If Richard is willing to do the work to make -kernel perform faster
in such a way that it fits into the overall mission of what we're
building, then I see no reason to reject it. The criteria for
evaluating a patch should only depend on how it
On 08/03/2010 09:55 PM, Anthony Liguori wrote:
On 08/03/2010 01:43 PM, Avi Kivity wrote:
If Richard is willing to do the work to make -kernel perform faster
in such a way that it fits into the overall mission of what we're
building, then I see no reason to reject it. The criteria for
On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote:
If Richard is willing to do the work to make -kernel perform
faster in such a way that it fits into the overall mission of what
we're building, then I see no reason to reject it. The criteria
for evaluating a patch should only
On 08/03/2010 10:05 PM, Gleb Natapov wrote:
That's true, but extending fwcfg doesn't fit into the overall
picture well. We have well defined interfaces for pushing data into
a guest: virtio-serial (dma upload), virtio-blk (adds demand
paging), and virtio-p9fs (no image needed). Adapting
On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote:
libguestfs does not depend on an x86 architectural feature.
qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We
should discourage people from depending on this interface for
production use.
I really don't get this whole
On 08/03/2010 02:05 PM, Gleb Natapov wrote:
On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote:
If Richard is willing to do the work to make -kernel perform
faster in such a way that it fits into the overall mission of what
we're building, then I see no reason to reject it. The
On Tue, Aug 03, 2010 at 08:13:46PM +0100, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote:
libguestfs does not depend on an x86 architectural feature.
qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We
should discourage people from
On 08/03/2010 02:13 PM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote:
libguestfs does not depend on an x86 architectural feature.
qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We
should discourage people from depending on this
On 08/03/2010 10:13 PM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote:
libguestfs does not depend on an x86 architectural feature.
qemu-system-x86_64 emulates a PC, and PCs don't have -kernel. We
should discourage people from depending on this interface
On 08/03/2010 10:15 PM, Anthony Liguori wrote:
fw_cfg has to be available pretty early on so relying on a PCI device
isn't reasonable. Having dual interfaces seems wasteful.
Agree.
We're already doing bulk data transfer over fw_cfg as we need to do it
to transfer roms and potentially a
On Tue, Aug 03, 2010 at 02:15:05PM -0500, Anthony Liguori wrote:
On 08/03/2010 02:05 PM, Gleb Natapov wrote:
On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote:
If Richard is willing to do the work to make -kernel perform
faster in such a way that it fits into the overall mission of
On 08/03/2010 02:24 PM, Avi Kivity wrote:
On 08/03/2010 10:15 PM, Anthony Liguori wrote:
fw_cfg has to be available pretty early on so relying on a PCI device
isn't reasonable. Having dual interfaces seems wasteful.
Agree.
We're already doing bulk data transfer over fw_cfg as we need
On 08/03/2010 10:38 PM, Anthony Liguori wrote:
Why do we need to transfer roms? These are devices on the memory bus
or pci bus, it just needs to be there at the right address.
Not quite. The BIOS owns the option ROM space. The way it works on
bare metal is that the PCI ROM BAR gets
On 08/03/2010 02:41 PM, Avi Kivity wrote:
On 08/03/2010 10:38 PM, Anthony Liguori wrote:
Why do we need to transfer roms? These are devices on the memory
bus or pci bus, it just needs to be there at the right address.
Not quite. The BIOS owns the option ROM space. The way it works on
On Tue, Aug 03, 2010 at 10:22:22PM +0300, Avi Kivity wrote:
On 08/03/2010 10:13 PM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote:
libguestfs does not depend on an x86 architectural feature.
qemu-system-x86_64 emulates a PC, and PCs don't have -kernel.
On Tue, Aug 03, 2010 at 12:37:18AM +0400, malc wrote:
Thare are whitespace issues in this patch.
Thanks for looking at the patch. Here is an updated patch, that
should fix the whitespace issues:
This is a block driver for the distributed file system Ceph
(http://ceph.newdream.net/). This
Tvrtko Ursulin tvrtko.ursu...@sophos.com writes:
On Tuesday 03 Aug 2010 16:17:20 Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 15:57:03 Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 15:51:08 Avi Kivity wrote:
On 08/03/2010 12:28 PM, Tvrtko Ursulin wrote:
I have basically built 2.6.35
On 08/03/2010 03:00 PM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 10:22:22PM +0300, Avi Kivity wrote:
On 08/03/2010 10:13 PM, Richard W.M. Jones wrote:
On Tue, Aug 03, 2010 at 09:43:39PM +0300, Avi Kivity wrote:
libguestfs does not depend on an x86 architectural
On Tue, Aug 3, 2010 at 8:59 AM, Tvrtko Ursulin
tvrtko.ursu...@sophos.com wrote:
On Tuesday 03 Aug 2010 16:17:20 Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 15:57:03 Tvrtko Ursulin wrote:
On Tuesday 03 Aug 2010 15:51:08 Avi Kivity wrote:
On 08/03/2010 12:28 PM, Tvrtko Ursulin wrote:
I
On 08/03/2010 10:49 PM, Anthony Liguori wrote:
On the other hand we end up with stuff like only being able to add 29
virtio-blk devices to a single guest. As best as I can tell, this
comes from PCI
No, this comes from us being too clever for our own good and not
following the way hardware
Hi,
We're already doing bulk data transfer over fw_cfg as we need to do it
to transfer roms and potentially a boot splash.
Why do we need to transfer roms? These are devices on the memory bus or
pci bus, it just needs to be there at the right address.
Indeed. We do that in most cases.
Hi,
Again I don't follow. We can just lay out the ROMs in memory like we did
in the past?
Well. We have some size issues then. PCI ROMS are loaded by the BIOS
in a way that only a small fraction is actually resident in the small
0xd - 0xe area. That doesn't work if qemu tries
On 08/03/2010 04:13 PM, Paolo Bonzini wrote:
On 08/03/2010 10:49 PM, Anthony Liguori wrote:
On the other hand we end up with stuff like only being able to add 29
virtio-blk devices to a single guest. As best as I can tell, this
comes from PCI
No, this comes from us being too clever for our
Hi,
I am seeing a performance degradation while using libvirt to start my
vm (kvm). vm is fedora 12 and host is also fedora 12, both with
2.6.32.10-90.fc12.i686. Here are the statistics from iperf :
From VM: [ 3] 0.0-30.0 sec 199 MBytes 55.7 Mbits/sec
From host : [ 3] 0.0-30.0 sec 331
On Tue, Aug 03, 2010 at 10:24:41PM +0300, Avi Kivity wrote:
Why do we need to transfer roms? These are devices on the memory
bus or pci bus, it just needs to be there at the right address.
Boot splash should just be another rom as it would be on a real
system.
Just like the initrd?
Rich.
On Tue, Aug 03, 2010 at 05:00:49PM +0800, Liu, Jinsong wrote:
I just test your new patch with Windows 2008 DataCenter at my
platform, it works OK! We can hot-add new cpus and they appear at
Device Manager. (BTW, yesterday I test your new patch with linux
2.6.32 hvm, it works fine, we can
Richard W.M. Jones wrote:
We could demand that OSes write device drivers for more qemu devices
-- already OS vendors write thousands of device drivers for all sorts
of obscure devices, so this isn't really much of a demand for them.
In fact, they're already doing it.
Result: Most OSes not
The Buildbot has detected a new failure of disable_kvm_x86_64_debian_5_0 on
qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_debian_5_0/builds/497
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build:
The Buildbot has detected a new failure of disable_kvm_i386_debian_5_0 on
qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_debian_5_0/builds/498
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build:
The Buildbot has detected a new failure of disable_kvm_x86_64_out_of_tree on
qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_x86_64_out_of_tree/builds/446
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build:
The Buildbot has detected a new failure of disable_kvm_i386_out_of_tree on
qemu-kvm.
Full details are available at:
http://buildbot.b1-systems.de/qemu-kvm/builders/disable_kvm_i386_out_of_tree/builds/446
Buildbot URL: http://buildbot.b1-systems.de/qemu-kvm/
Buildslave for this Build:
Arnd Bergmann wrote:
On Friday 30 July 2010 17:51:52 Shirley Ma wrote:
On Fri, 2010-07-30 at 16:53 +0800, Xin, Xiaohui wrote:
Since vhost-net already supports macvtap/tun backends, do you think
whether it's better to implement zero copy in macvtap/tun than
inducing a new media passthrough
The patch adds a new member get_idt() to x86_emulate_ops.
It also adds a function to get the idt in order to be used by the emulator.
This is needed for real mode interrupt injection and the emulation of int
instructions.
Signed-off-by: Mohammed Gamal m.gamal...@gmail.com
---
This function is used by KVM to pin process's page in the atomic context.
Define the 'weak' function to avoid other architecture not support it
Acked-by: Nick Piggin npig...@suse.de
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
---
mm/util.c | 13 +
1 files changed,
1 - 100 of 108 matches
Mail list logo
