On Thu, 2008-02-28 at 00:22 -0500, Haydn Solomon wrote:
First of all, thank you for all the great work on this project.
I am trying to boot a linux guest from virtio block device. I followed
the howto on the wiki but guest is not able to locate root device.
Only thing I am doing
Hello
You must add root=/dev/vdaX, where X is number of your boot partition,
to kernel boot parameters. In lilo.conf you must add this to append line.
Have a nice day
Haydn Solomon napsal(a):
First of all, thank you for all the great work on this project.
I am trying to boot a linux guest
Hollis Blanchard wrote:
It doesn't have to be a package; it can be as simple as a tarball that
people have to make; sudo make install before compiling kvm, the same
as other prerequisite libraries.
Sure. Let's put that tarball inside the qemu directory, and then have it
extracted
Jerone Young wrote:
Recent pull of qemu_cvs has added function qemu_system_cpu_hot_add to the
function do_cput_set_nr in monitor.c . Issue is qemu_system_cpu_hot_add is
defined in acpi.c which is only compiled for arch with target base i386
(which are i386 x86-64).
Applied, thanks.
Hollis Blanchard wrote:
On Wed, 2008-02-27 at 16:14 -0600, Jerone Young wrote:
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED]
# Date 1204150440 21600
# Branch merge
# Node ID f255b23b6ef9461be4ee18fa0745f30c4fb66e6a
# Parent 64a281615f436e65ca7fb2f3c2721c374fbfc8be
Fix
Jerone Young wrote:
This patch adds a line to the help screen of configure for qemu to show the
option --disable-cpu-emulation
Applied, thanks.
--
error compiling committee.c: too many arguments to function
-
This
Hello
I test virtio block device. I can boot from vda as root partition, but
if I want to install lilo into boot sector, lilo give me this error:
Fatal: Linux experimental device 0x04x needs to be defined.
Check 'man lilo.conf' under 'disk=' and 'max-partitions='
I boot it like this:
kvm
ציטוט Andrea Arcangeli:
Same as before but one one hand ported to #v7 API and on the other
hand ported to latest kvm.git.
Signed-off-by: Andrea Arcangeli [EMAIL PROTECTED]
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 41962e7..e1287ab 100644
--- a/arch/x86/kvm/Kconfig
+++
Bugs item #1903732, was opened at 2008-02-28 16:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=1903732group_id=180599
Please note that this message will contain a full copy of
On Thu, Feb 28, 2008 at 09:40:00AM +0100, Tomas Rusnak wrote:
I test virtio block device. I can boot from vda as root partition, but
if I want to install lilo into boot sector, lilo give me this error:
Fatal: Linux experimental device 0x04x needs to be defined.
Check 'man lilo.conf' under
Hi, all,
This is today's KVM test result against kvm.git
4a7f582a07e14763ee4714b681e98b3b134d1d46 and kvm-userspace.git
bc6db37817ce749dcc88fbc761a36bb8df5cf60a.
LTP and kernel build test on pae linux guest are failed, because these
case boot guests with smp 2.6.9 kernel, it's related with
Chris Wedgwood napsal(a):
On Thu, Feb 28, 2008 at 09:40:00AM +0100, Tomas Rusnak wrote:
I test virtio block device. I can boot from vda as root partition, but
if I want to install lilo into boot sector, lilo give me this error:
Fatal: Linux experimental device 0x04x needs to be defined.
On Thu, Feb 28, 2008 at 10:11:30AM +0100, Tomas Rusnak wrote:
Check 'man lilo.conf' under 'disk=' and 'max-partitions='
Thank you for your quick answer, but this doesn't help. After i run
lilo, it give me the same error message.
did you try adding 'max-partitions=16' or similar?
Chris Wedgwood napsal(a):
On Thu, Feb 28, 2008 at 10:11:30AM +0100, Tomas Rusnak wrote:
Check 'man lilo.conf' under 'disk=' and 'max-partitions='
Thank you for your quick answer, but this doesn't help. After i run
lilo, it give me the same error message.
did you try adding
On Thu, Feb 28, 2008 at 10:25:49AM +0100, Tomas Rusnak wrote:
But max-partitions=16 give you bad value.
I suggested 16 because that's what the called to alloc_disk in the
virtio block driver is using. I'm not sure why lilo dislikes that
value.
Now I can boot it correctly. Thank you very much
repository: /home/build/src/kvm
branch: trunk
commit cd5edbab7d647b81cbbf60d530068f2916658753
Author: Dor Laor [EMAIL PROTECTED]
Date: Thu Feb 28 11:01:41 2008 +0200
Change the e1000 mmio addr space according to spec.
According to the Intel 82540EM manual, the mmio space is
Chris Wedgwood napsal(a):
On Thu, Feb 28, 2008 at 10:25:49AM +0100, Tomas Rusnak wrote:
But max-partitions=16 give you bad value.
I suggested 16 because that's what the called to alloc_disk in the
virtio block driver is using. I'm not sure why lilo dislikes that
value.
Now I can boot
On Thu, Feb 28, 2008 at 01:52:50AM +0100, Andrea Arcangeli wrote:
On Wed, Feb 27, 2008 at 04:14:08PM -0800, Christoph Lameter wrote:
Erm. This would also be needed by RDMA etc.
The only RDMA I know is Quadrics, and Quadrics apparently doesn't need
to schedule inside the invalidate methods
Haydn Solomon wrote:
I didn't create the initrd with the modules preloaded. Still not
working yet but I'm wondering... will this work with LVM volumes?
It's actually easier since you don't have to change your root= line.
--
error compiling committee.c: too many arguments to function
On Wed, 2008-02-27 at 16:47 -0600, Hollis Blanchard wrote:
On Wed, 2008-02-27 at 16:34 -0600, Jerone Young wrote:
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED]
# Date 1204151598 21600
# Branch merge
# Node ID cd9eab52ef2d78809540518c4e18f4730d5d8400
# Parent
Whoops ok looks like I made a mistake with the help text. I use
--no-cpu-emulation .. when I meant --disable-cpu-emulation that was
in the summary. I think I got my self screwedup by the defines we use in
the code. This is what Hollis was pointing out.
Here is a more proper patch.
Signed-off-by:
Ok, got it to work. Like the docs said, I needed to be careful with ramdisk;
I didn't install enough modules in the ramdisk first time around. The
Fedora9 vm is booting up much faster on virtio but haven't done any official
timings. Network seems to be performing faster too when downloading big
On Thu, 28 Feb 2008, Andrea Arcangeli wrote:
On Wed, Feb 27, 2008 at 05:03:21PM -0800, Christoph Lameter wrote:
RDMA works across a network and I would assume that it needs confirmation
that a connection has been torn down before pages can be unmapped.
Depends on the latency of the
Cam Macdonell wrote:
Hi,
To be clear, do you have VMGL running? And you're only getting ~35 FPS?
For me, using VMGL doubles the performance of glxgears on two different
machines. As well, I'm using the Enemy Territory demos the author
used and they are usable with VMGL but still jumpy.
Attached is a repost of the preliminary patch implementing USB 2.0 EHCI
emulation.
I want to start testing your patches for the EHCI stuff. Do i need
to enable anything inorder to get EHCI emulation working after
applying your patch?
Unfortunately, with this patch it doesn't work for me.
On Wed, 27 Feb 2008, Andrea Arcangeli wrote:
What Christoph need to do when he's back from vacations to support
sleepable mmu notifiers is to add a CONFIG_XPMEM config option that
will switch the i_mmap_lock from a semaphore to a mutex (any other
change to this patch will be minor compared to
On Wed, 27 Feb 2008, Roland Dreier wrote:
http://git.kernel.org/?p=linux/kernel/git/viro/vfs-2.6.git;a=commit;h=49be4f8114e6ff0efdab10ebba2493fb67bc3034
Actually, looking closer at the kvm changes here, I think that
create_vcpu_fd() needs the same treatment as kvm_dev_ioctl_create_vm()
If we let the caller call fd_install(), then it may be messed up WRT
cleanup (fd, file, inode).
Yes, that is a tiny bit tricky (need to call put_unused_fd() if you
don't install the fd).
How about removing the inode pointer handout altogether, and *doing*
fd_install() inside
So I forgot to CC all the interested parties on this list (sorry about
that I wasn't thinking at the time), but I did start up a conversation
on linuxppc-dev on the subject of splitting out libfdt from dtc. Mainly
to get the thought of what the dtc folks thought about splitting out
libfdt.
The
Anthony Liguori wrote:
If someone posts a simple howto with how to setup VMGL in a guest and
host, I'll take a look at it this weekend and see if I can't increase
the FPS by tweaking the virtio network driver.
virtio should get very good throughput but the latencies aren't very
optimized
On Thu, Feb 28, 2008 at 11:48:10AM -0800, Christoph Lameter wrote:
make it work after the VM locking will be altered (for example the
^^^
CONFIG_XPMEM should also switch the mmu_register/unregister locking
On Thu, 28 Feb 2008, Andrea Arcangeli wrote:
This is not going to work even if the mutex would work as easily as you
think since the patch here still does an rcu_lock/unlock around a callback.
See underlined.
Mutex is not acceptable for performance reasons. I think we can just drop
the
Tomas Rusnak wrote:
Chris Wedgwood napsal(a):
On Thu, Feb 28, 2008 at 10:11:30AM +0100, Tomas Rusnak wrote:
Check 'man lilo.conf' under 'disk=' and 'max-partitions='
Thank you for your quick answer, but this doesn't help. After i run
lilo, it give me the same error message.
did you try
This patch changes -hugetlb-path to -mem-path and also updates the code so that
it works for hugetlbfs or tmpfs.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/qemu/vl.c b/qemu/vl.c
index c9ed3f0..2896024 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -237,8 +237,7 @@ int
On Wed, 27 Feb 2008, Andrea Arcangeli wrote:
+struct mmu_notifier_head {
+ struct hlist_head head;
+ spinlock_t lock;
+};
Still think that the lock here is not of too much use and can be easily
replaced by mmap_sem.
+#define mmu_notifier(function, mm, args...)
The release should be called much earlier to allow the driver to release
all resources in one go. This way each vma must be processed individually.
For our gobs of memory this method may create a scaling problem on exit().
Good point, it has to be called earlier for GRU, but it's not a
On Thu, Feb 28, 2008 at 05:17:33PM -0600, Jack Steiner wrote:
I disagree. The location of the callout IS a performance issue. In simple
comparisons of the 2 patches (Christoph's vs. Andrea's), Andrea's has a 7X
increase in the number of TLB purges being issued to the GRU. TLB flushing
Are you
On Thu, Feb 28, 2008 at 03:05:30PM -0800, Christoph Lameter wrote:
Still think that the lock here is not of too much use and can be easily
replaced by mmap_sem.
I can use the mmap_sem.
+#define mmu_notifier(function, mm, args...)
\
+ do {
On Thu, Feb 28, 2008 at 10:43:54AM -0800, Christoph Lameter wrote:
What about invalidate_page()?
That would just spin waiting an ack (just like the smp-tlb-flushing
invalidates in numa already does).
Thinking more about this, we could also parallelize it with an
invalidate_page_before/end. If
On Fri, 29 Feb 2008 01:40:01 +0100 Andrea Arcangeli [EMAIL PROTECTED] wrote:
+#define mmu_notifier(function, mm, args...)
\
+ do {\
+ struct mmu_notifier *__mn;
On Fri, 29 Feb 2008, Andrea Arcangeli wrote:
On Thu, Feb 28, 2008 at 10:43:54AM -0800, Christoph Lameter wrote:
What about invalidate_page()?
That would just spin waiting an ack (just like the smp-tlb-flushing
invalidates in numa already does).
And thus the device driver may stop
On Fri, 29 Feb 2008, Andrea Arcangeli wrote:
Also re the _notify variants: The binding to pte_clear_flush_young etc
will become a problem for notifiers that want to sleep because
pte_clear_flush is usually called with the pte lock held. See f.e.
try_to_unmap_one, page_mkclean_one etc.
On Fri, 29 Feb 2008, Andrea Arcangeli wrote:
On Thu, Feb 28, 2008 at 05:17:33PM -0600, Jack Steiner wrote:
I disagree. The location of the callout IS a performance issue. In simple
comparisons of the 2 patches (Christoph's vs. Andrea's), Andrea's has a 7X
increase in the number of TLB
Avi, Eddie,
I have a kernel-newbie question related to this thread. I think that Yang's
mentioned case that TSC between different vcpus doesn't sync could
also happen with physical cpus. Namely I think a OS running on bare metal
hardware need to handle the unsynced TSC between physical cpus. But
On Thu, Feb 28, 2008 at 1:55 PM, Cam Macdonell [EMAIL PROTECTED] wrote:
Anthony Liguori wrote:
If someone posts a simple howto with how to setup VMGL in a guest and
host, I'll take a look at it this weekend and see if I can't increase
the FPS by tweaking the virtio network driver.
Looks good, please apply.
Thanks.
On Thu, Feb 28, 2008 at 04:46:58PM -0600, Anthony Liguori wrote:
This patch changes -hugetlb-path to -mem-path and also updates the code so
that
it works for hugetlbfs or tmpfs.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
In hw/pc.c, replace usb_uhci_piix3_init(pci_bus, piix3_devfn + 2);
With usb_ehci_init(pci_bus, piix3_devfn + 2);
Note my comments on the original post:
-tested on XP guest
-does not support ISO transfers
-timing issues
-Original Message-
From: Gerb Stralko [mailto:[EMAIL PROTECTED]
Sent:
47 matches
Mail list logo
