Blue Swirl wrote:
On 3/30/08, Anthony Liguori [EMAIL PROTECTED] wrote:
Blue Swirl wrote:
On 3/30/08, Anthony Liguori [EMAIL PROTECTED] wrote:
This patch introduces a PCI DMA API and some generic code to support
other DMA
APIs. Two types are introduced: PhysIOVector
Paul Brook wrote:
On Sunday 30 March 2008, Anthony Liguori wrote:
The entity processing the data shouldn't need to know or care how the
translation is done. PhysIOVector should describe everything it need to know.
Okay, I'll update.
What could work is if the DMA API functions mapped
CONFIG_VIRTUALIZATION=y
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_BALLOON=y
You're probably missing:
CONFIG_KVM_CLOCK=y
CONFIG_KVM_GUEST=y
Regards,
Anthony Liguori
-
Check out the new SourceForge.net
Alexander Graf wrote:
On Mar 30, 2008, at 9:44 PM, Anthony Liguori wrote:
Felix Leimbach wrote:
While testing the new virtio drivers in linux-2.6.25 my test
2.6.25-rc7-git5 guest with paravirt support running in KVM-64 thinks it
sits on cold and unfriendly bare metal instead of a safe
Dor Laor wrote:
On Sat, 2008-03-29 at 16:55 -0500, Anthony Liguori wrote:
This patch introduces virtio support over PCI. virtio is a generic virtual
IO
framework for Linux first introduced in 2.6.23. Since 2.6.25, virtio has
supported a PCI transport which this patch implements
Avi Kivity wrote:
Anthony Liguori wrote:
#define s_ld_u64(phys, field, type) \
ldq_phys(phys + offsetof(field, type))
And now we don't need individual accessors, or to encode the offsets
as magic numbers.
It's a nice thought but it doesn't work out in practice because
This patch implements the virtio block driver backend.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/Makefile.target b/Makefile.target
index 3ea40d1..f9fe660 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -535,7 +535,7 @@ OBJS += rtl8139.o
OBJS += e1000.o
# virtio
when using this driver.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/Makefile.target b/Makefile.target
index f9fe660..86a0bf5 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -535,7 +535,7 @@ OBJS += rtl8139.o
OBJS += e1000.o
# virtio devices
-OBJS += virtio.o virtio-net.o
uint32_t is the wrong type to use to represent physical addresses.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/cpu-all.h b/cpu-all.h
index 2a2b197..9e5d33b 100644
--- a/cpu-all.h
+++ b/cpu-all.h
@@ -834,7 +834,7 @@ typedef uint32_t CPUReadMemoryFunc(void *opaque
to be preformed without introducing assumptions of
phys_ram_base. This API is at the PCI device level to enable support of
per-device IOMMU remapping.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/Makefile.target b/Makefile.target
index 5ac29a7..94f3e58 100644
--- a/Makefile.target
+++ b
This patch implements the virtio network driver backend. In KVM, this driver
can achieve 1gbit tx/rx performance. More patches are required to improve the
network IO infrastructure to achieve better performance in QEMU.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git
the proper access functions to manipulate guest memory.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/Makefile.target b/Makefile.target
index 94f3e58..6815ba8 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -534,6 +534,9 @@ OBJS += pcnet.o
OBJS += rtl8139.o
OBJS += e1000.o
. That simplifies the virtio-blk support quite a bit. We also
need to implement a reset handler when we introduce aio support that
cancels and pending aio requests.
Regards,
Anthony Liguori
-
Check out the new SourceForge.net
got a virtio patch series that changes the virtqueue_pop()
interface to return a pointer to a VirtQueueElement which I believe
addresses your use-case.
I can just fold your patch into my series (I'll be sending it out this
afternoon).
Regards,
Anthony Liguori
Index: kvm-userspace.io/qemu/hw
like it's going to be a performance problem but yeah, I
was thinking the same thing.
Regards,
Anthony Liguori
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything
Avi Kivity wrote:
Anthony Liguori wrote:
#define s_ld_u64(phys, field, type) \
ldq_phys(phys + offsetof(field, type))
And now we don't need individual accessors, or to encode the offsets
as magic numbers.
It's a nice thought but it doesn't work out in practice because
copy or a full blown DMA API.
This patch should make it easier to use virtio with QEMU (in the absence of
KVM).
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/qemu/hw/virtio-net.c b/qemu/hw/virtio-net.c
index 3d54c4e..e1b0aad 100644
--- a/qemu/hw/virtio-net.c
+++ b/qemu/hw/virtio
. That
doesn't seem to be terribly valuable though from a history perspective
as it still requires a bit of code change to keep things working. Were
you thinking of something else?
Regards,
Anthony Liguori
-
Check out the new
this makes the code much easier to understand.
Since v1=v2, we make sure to use common code for save/restore between
in-kernel pit and in-qemu pit.
This patch also fixes the build for PPC.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
) versions of GCC that it won't build with whereas
the error being reported is not valid.
This is okay for developers, but not for users. In general, most
projects reserve -Werror for a developer or maintainer mode.
Regards,
Anthony Liguori
Often I miss these warnings as they scroll right
Avi Kivity wrote:
Anthony Liguori wrote:
Hollis Blanchard wrote:
This patch solves annoying qemu build breakage hitting PowerPC around
struct kvm_pit_state, so that's another vote in favor...
I have an updated version of the patch but it's breaking the build b/c
to make any specific changes to the guest to make it
recognize/detect the volume-group on the virtual block device?
You need to make sure virtio_blk and virtio_pci are included in your initrd.
Regards,
Anthony Liguori
Regards,
Dennis
,
Anthony Liguori
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm
.
Regards,
Anthony Liguori
Christian Borntraeger wrote:
include/linux/kvm.h defines struct kvm_dirty_log to
[...]
union {
void __user *dirty_bitmap; /* one bit per page */
__u64 padding;
};
__user requires compiler.h to compile. Currently
send it out again once I
figure out the fix for this linux/compiler.h.
Regards,
Anthony Liguori
qemu:cleanup_pit.patch
Description: application/mbox
-
This SF.net email is sponsored by: Microsoft
Defy all challenges
that each
guest userspace copies only the rx packets. That's about as secure as
you're going to get with this approach I think.
Regards,
Anthony Liguori
My feeling is that the host needs to copy the data, using dma if
available. Another option is to have one guest map the other's memory
for communication, unlink the file immediately after open,
and then pass the fd via SCM_RIGHTS to the other process.
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R
something new to determine the true common subset.
I haven't tuned or even benchmarked these patches, but it pings!
Very nice! It's particularly cool that it was possible entirely in
userspace.
Regards,
Anthony Liguori
Rusty
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
Each guest's host userspace mmaps the other guest's address space.
The userspace then does a copy on both the tx and rx paths.
Well, that's better security-wise (I'd still prefer to avoid it, so we
can run each guest under
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
Anthony Liguori wrote:
Avi Kivity wrote:
Each guest's host userspace mmaps the other guest's address space.
The userspace then does a copy on both the tx and rx paths.
Well, that's better security-wise (I'd still prefer
Avi Kivity wrote:
Anthony Liguori wrote:
Rusty Russell wrote:
From: Paul TBBle Hampson [EMAIL PROTECTED]
This creates a file in $HOME/.lguest/ to directly back the RAM and
DMA memory
mappings created by map_zeroed_pages.
I created a test program recently that measured
guest's address spaces
and do the copying on behalf of each guest if you're paranoid about
escaping into QEMU.
[Driver domains are a horrible idea IMO, but that's another story]
I don't disagree :-)
Regards,
Anthony Liguori
switch. I'll have patches soon.
Regards,
Anthony Liguori
Cheers,
Rusty.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt
though--the host just doesn't reclaim the memory
immediately.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index d0cde54..c0205d7 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -574,7 +574,7 @@ OBJS += e1000.o
OBJS
that you were on.
Regards,
Anthony LIguori
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01
for things like RHEL4.
Regards,
Anthony Liguori
david
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01
if you just did a ./configure make
install, your binary would be in /usr/local/bin
Regards,
Anthony Liguori
Details:
Intel(R) Core(TM)2 Extreme CPU Q6850 @ 3.00GHz
kvm-63
Kernel 2.6.24.2
x86_64
Guest is Windows 32bit 2003 Standard
Any insight is appreciated, works with model=rtl8139
);
+cpu_physical_memory_write_rom(hdr-ih_load, uncompressed_data,
+tmp_loaded_image_size);
+}
+else {
You've still got braces issues.
Regards,
Anthony Liguori
-
This SF.net email is sponsored
);
Need to pass a permission mask when using O_CREAT.
Regards,
Anthony LIguori
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt
Make sure to call unregister_virtio_device() when a virtio device is removed.
Otherwise, virtio_pci.ko cannot be rmmod'd.
This was spotted by Marcelo Tosatti.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
index 59a8f73
suggest
dropping the local changes and I'll investigate further.
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go
. What would be most helpful
is actually submitting a patch to that repo that did the awk/cpp magic
to generate the backport.
Regards,
Anthony Liguori
I have the virtio drivers working with RHEL4. The virtio_net appears to be
working better than e1000 for the workload I am testing with (though I
accurate. If userspace has a better time mechanism,
like hrtimer, then it can just use that. If hrtimer is good enough in
userspace, then we can contain these new ioctls to the compat-code only.
Regards,
Anthony Liguori
Before implementing yet another in-kernel device I like to hear
opinions
not getting even a 1% performance
boost and you're adding a lot of complexity to the kernel. This
strongly suggests to me that we should be doing this in userspace.
Regards,
Anthony Liguori
-
This SF.net email is sponsored
an increased accuracy, there won't be an improvement.
Do ya'll see an improvement playing multimedia on a 2.6.24 host with the
in-kernel PIT?
Regards,
Anthony Liguori
Note that we also need support for older host kernels.
Before implementing yet another in-kernel device I like to hear
opinions
Jerone Young wrote:
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED]
# Date 1205514174 18000
# Branch merge
# Node ID 3060b75a9597d4ab67c23871df41fc5e5476df2b
# Parent 63237bde74818a5dc3cdb1baee781dab101290ce
Add ability to specify ram on command line for bamboo board model
Instead of having an explicit --enable-libfdt, it would be nicer to
compile probe for it and then provide a --disable-libfdt option. Then
it Just Works without a special configure flag.
Regards,
Anthony Liguori
Jerone Young wrote:
# HG changeset patch
# User Jerone Young [EMAIL PROTECTED
this makes the code much easier to understand.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 67a433e..2579688 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -585,6 +585,9 @@ OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW
it is :-/
Test case is any Fedora boot.iso or live CD from the past year or so.
Unfortunately, setting the BAR registers doesn't work under KVM. It
works fine in QEMU so it's probably a KVM bug. I'll look into it when I
get a chance.
Regards,
Anthony Liguori
Jeremy
from disk. On the other hand, NPT
guests are likely to be very sensitive to evicting things from the
shadow page cache. I would think it's pretty clear that in the NPT
case, the MMU cache should have a higher seek cost than the default.
Regards,
Anthony Liguori
Dor Laor wrote:
On Wed, 2008-03-12 at 12:38 -0500, Anthony Liguori wrote:
Part of the feedback we received from Fabrice about the KVM patches
for QEMU
is that we should create a separate device for the in-kernel APIC to
avoid
having lots of if (kvm_enabled()) within the APIC code
slirp.
FWIW, you'll probably get a better return on time investment by getting
yourself going with tap. If you use dnsmasq in the host, you can setup
DNS, DHCP, TFTP, and BOOTP very easily.
Regards,
Anthony Liguori
I can scp a very small file to a kvm-60 guest in ~3 seconds. The same
file
to
validate that the registered region is a power of two in size.
Regards,
Anthony Liguori
Index: kvm-userspace.hotplug2/qemu/hw/pci.c
===
--- kvm-userspace.hotplug2.orig/qemu/hw/pci.c
+++ kvm-userspace.hotplug2/qemu/hw/pci.c
to have the monitor sit on a
unix domain socket or on a TCP socket and you can issue commands to the
monitor via a tool like socat.
libvirt is by far the simplest choice for managing KVM but it's possible
to do these things without it.
Regards,
Anthony Liguori
Thanks
Matthias
think we should have a more compelling
reason to do it if we truly have to.
2) Handle the case where we get nonsense from the host, which causes us to
wrap around.
Here's my neither compiled nor tested version which should fix this
problem without breaking the ABI.
Regards,
Anthony
it.
It should just be a matter of doing a make make install in the guest.
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com
,
No, AFAIK we don't need any support from the host kernel. We just need a
virtio backend to be present in qemu, which is there in the latest
kvm-userspace.
Correct. In the future, we may have kernel backends but you should
still be able to use the userspace backends.
Regards,
Anthony
infrastructure makes it tough to integrate it properly though.
Regards,
Anthony Liguori
Here is a block diagram representing the test.
+---+
| Virtual Machine |
| |
| Read/Write with O_DIRECT
taskset :-)
Regards,
Anthony Liguori
[I'd like to see how Xen implements swapping, though]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go
Dor Laor wrote:
On Tue, 2008-03-04 at 18:50 -0600, Anthony Liguori wrote:
Dor Laor wrote:
I thought there was some discussion about whether -tdf was every useful
in practice?
It works.
Just try to play a movie in windows standard HAL with and w/o -tdf
--no-irq-chip
should see the proper proportions.
Regards,
Anthony Liguori
diff --git a/qemu/hw/virtio-blk.c b/qemu/hw/virtio-blk.c
index 301b5a1..3c56bed 100644
--- a/qemu/hw/virtio-blk.c
+++ b/qemu/hw/virtio-blk.c
@@ -71,59 +71,121 @@ typedef struct VirtIOBlock
BlockDriverState *bs;
} VirtIOBlock
,
Anthony Liguori
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm
://www.kernel.org/pub/scm/virt/kvm/kvm-guest-drivers-linux.git
I'll just kill my mercurial repository.
Regards,
Anthony Liguori
Cheers,
Dor
Thanks for the report,
Rusty.
___
Lguest mailing list
[EMAIL PROTECTED]
https://ozlabs.org/mailman
at the -mem-file implementation in the latest git, you'll
see that all the guest's memory can be an mmap()'d file.
Regards,
Anthony Liguori
Thanks,
Cam
-
This SF.net email is sponsored by: Microsoft
Defy all challenges
? From your
mails, you're claiming it increases the timer accuracy. How are you
measuring it and how much does it improve it?
Do you expect an overall performance improvement from this or is it
simply about improving timer accuracy?
Regards,
Anthony Liguori
is to implement the read drive parameters function and return the
actual numbers of sectors. This requires changing the QEMU = extboot
interface as this was not previously passed to extboot.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/extboot/extboot.S b/extboot/extboot.S
index 584d36d
!
So why exactly is this useful? I have a hard time constructing a
reasonable use-case in my mind for something like this.
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Microsoft
Defy all challenges
because Xen does it doesn't imply that we should do it.
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt
host-guest pci device pass-through.
There is symmetry with pci_add and usb_add since usb_add takes either a
USB device identifier or the name of an emulated device along with
parameters. So I prefer the pci_add syntax just to maintain consistency
with the rest of QEMU.
Regards,
Anthony
the slot
number with higher level information about the device.
Regards,
Anthony Liguori
Regards,
Dan.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http
Dor Laor wrote:
On Tue, 2008-03-04 at 09:52 -0600, Anthony Liguori wrote:
Yang, Sheng wrote:
Hi
Here is the last in-kernel PIT patch for KVM. The mainly change from last
version is the supporting to save/restore. I also tested live migration.
The other modifies including some
Glauber Costa wrote:
Anthony Liguori wrote:
No, it can't. Because at the time qemu starts, no vcpu - thread id
relationship exists at all. And we don't know when it will.
Sure we do. The vcpu - thread id relationship is valid after
kvm_init_ap() is called which is after machine init
Yang, Sheng wrote:
On Wednesday 05 March 2008 08:50:24 Anthony Liguori wrote:
So how do we measure the benefits of an in-kernel PIT?
On the time accuracy side, one typical example is in RHEL5 32E guest, time
flows very slow compared to the host
(https://sourceforge.net/tracker
-vq[i].vring.used,
TARGET_PAGE_SIZE);
I think these two need to be sizeof(VRingAvail) * vring.num and
sizeof(VringUsed) * vring.num
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Microsoft
Defy all
Avi Kivity wrote:
Anthony Liguori wrote:
If you are using virtio drivers in the guest (which I presume you are
given the reference to /dev/vda), try using the following -drive syntax:
-drive file=/dev/mapper/ioband1,if=virtio,boot=on,cache=off
This will force the use of O_DIRECT
virtio-pci acquires its spin lock in an interrupt context so it's necessary
to use spin_lock_irqsave/restore variants. This patch fixes guest SMP when
using virtio devices in KVM.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio
using the following -drive syntax:
-drive file=/dev/mapper/ioband1,if=virtio,boot=on,cache=off
This will force the use of O_DIRECT. By default, QEMU does not open
with O_DIRECT so you'll see page cache effects.
Regards,
Anthony Liguori
throughput but the latencies aren't very
optimized yet so if VMGL is latency sensitive, this may be what you're
seeing. I don't know what is normal to expect from VMGL though.
Regards,
Anthony Liguori
Thanks,
Cam
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
the author well.
Does From have to be the first line? git-send-email never seems to do
anything with From for me.
Regards,
Anthony Liguori
Anyway I applied all these patches, including the vmware BAR patch since
it's a dependency
package for it.
Regards,
Anthony Liguori
L'email della prossima generazione? Puoi averla con la nuova Yahoo!
Mail
http://us.rd.yahoo.com/mail
of catastrophe (like a kill
-SIGKILL).
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01
% improvement in
performance with this patch with a 4-VCPU guest.
Very nice work!
Regards,
Anthony Liguori
Signed-off-by: Marcelo Tosatti [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges
[EMAIL PROTECTED] wrote:
I looked for a gz o bz archive. Is there a tarball with gfxboot
disable program (URL)?
I'm not sure I understand your question but the only way to get
gfxboot-disable today is through mercurial.
Regards,
Anthony Liguori
Thanks
change -hugetlb-path to -mem-path for now (and
test it with tmpfs). Not so fond of hardcoding a path in QEMU though.
If we had a unified tmpfs/hugetlbfs, I think it would make a lot of
sense. I think I need to ask around though first and see how reasonable
that is.
Regards,
Anthony Liguori
height is 36 pixels which looks like a cursor size to me. This
is true with or without the BAR patch though. I'll look into it a
little more and see what's going on.
Regards,
Anthony Liguori
I just launched the VM and checked what kind of Ms Windows set up this
is and it's a Windows XP
This function is useful for enabling KVM support in VMware VGA.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/qemu/hw/vga.c b/qemu/hw/vga.c
index 222a39c..1cfc154 100644
--- a/qemu/hw/vga.c
+++ b/qemu/hw/vga.c
@@ -1813,6 +1813,36 @@ typedef struct PCIVGAState {
VGAState
vmware_vga.c uses functions in vga.c to do some things. They
need to agree on which parts of their state struct is common
and which aren't, otherwise they'll overwrite parts of each
other's state. This patch makes it so.
Signed-off-by: Soren Hansen [EMAIL PROTECTED]
Reviewed-by: Anthony Liguori
removes the explicit BARs and registers the second region through
the normal PCI code.
I've only tested with a Linux guest and the open source VMware VGA driver.
This patch needs -p2 to apply against the QEMU CVS tree.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/qemu/hw
Anthony Liguori wrote:
Right now we set explict base addresses for the PCI IO regions in the VMware
VGA device. We don't register the second region at all and instead directly
map the physical memory.
The problem is, the addresses we're setting in the BAR is not taken into
account
andrzej zaborowski wrote:
On 22/02/2008, Anthony Liguori [EMAIL PROTECTED] wrote:
Right now we set explict base addresses for the PCI IO regions in the VMware
VGA device. We don't register the second region at all and instead directly
map the physical memory.
The problem
cost.
Signed-off-by: Anthony Liguori [EMAIL PROTECTED]
diff --git a/libkvm/kvm-common.h b/libkvm/kvm-common.h
index f4040be..d4df1a4 100644
--- a/libkvm/kvm-common.h
+++ b/libkvm/kvm-common.h
@@ -19,7 +19,7 @@
/* FIXME: share this number with kvm */
/* FIXME: or dynamically alloc/realloc regions
to
enable it on the command line? Without my own virtio enabled kernel
things work just fine.
Please post your command line for launching KVM. Make sure you have a
root parameter like root=/dev/vda1.
Regards,
Anthony Liguori
Thanks
- Thomas
PS: maybe a kvm-users mailinglist was more
should be the only block driver you need in the
guest unless you want to give the guest a cdrom (which requires IDE).
The virtio block protocol should support everything needed to expose a
CDROM to a guest but we haven't implemented backend support for it yet.
Regards,
Anthony Liguori
thanks
(but in a less hackish way) would be to simply use
the host's vm86 mode instead of vm86 mode within the guest's VT context.
However, this does not fix big real mode. For that, you need to do
proper 16-bit instruction emulation.
Regards,
Anthony Liguori
of hardware.
Then we can use mechanisms like QEMU's CPU support to enable additional
features that may be available and unique to the underlying hardware.
It's then up to the management tools to deal with migratability since
they've explicitly enabled the feature.
Regards,
Anthony Liguori
if the hypercall batching is very useful.
Regards,
Anthony Liguori
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01
disabled. When we eventually support big real mode in the
kernel, we can disable this.
[1] http://hg.codemonkey.ws/gfxboot-disable
Regards,
Anthony Liguori
Signed-off-by: Alexander Graf [EMAIL PROTECTED
that stubs
out the functions that are no longer defined (something done by Anthony
Liguori attempting to fix qemu_cvs). What do folks think about this
approach, for us all we really need is a qemu that is not built with tcg
dependency.
Since a target in qemu is a cpu type, how
get their hands
on gcc-3 and only wish to run KVM.
Regards,
Anthony Liguori
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 49b81df..8b0436b 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -179,11 +179,17 @@ all: $(PROGS
201 - 300 of 847 matches
Mail list logo
