u measuring the improvements from an in-kernel PIT? 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 improvin
s(f, &vdev->vq[i].index);
> +
> +/* Save the descriptor ring instead of constantly mark them dirty */
> +qemu_put_buffer(f, (uint8_t*)vdev->vq[i].vring.desc,
> vdev->vq[i].vring.num * sizeof(VRingDesc));
> + qe
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/dri
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
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. By default, QEMU does not open
with O_DIRECT so you'll
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
PS by tweaking the virtio network driver.
virtio should get very good 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 nor
author" while Reviewed-by means "I know 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, incl
d the update
region 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
around though first and see how reasonable
that is.
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/
[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 Liguor
eing kernbench get about a 4% 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 e
perror("mmap");
> + hpagesize = 0;
> + exit(0);
> + }
> +
> + hugetlbfile = filename;
> + atexit(cleanup_hugetlb);
>
Instead of registering an atexit() handler, I think it would be better
to unlink immediately after doing the
the development package for it.
Regards,
Anthony Liguori
>
>
> L'email della prossima generazione? Puoi averla con la nuova Yahoo!
>
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
>>
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 no
This patch 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]>
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]>
Reviewe
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 {
VG
After the previous patches, this patch is pretty straight forward.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/vmware_vga.c b/qemu/hw/vmware_vga.c
index ec7b1cd..f2a298e 100644
--- a/qemu/hw/vmware_vga.c
+++ b/qemu/hw/vmware_vga.c
@@ -36,6 +36,9 @@
# i
ivial 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/real
because Xen uses vm86 mode within the host whereas KVM
uses vm86 mode in the guest's VT context. An alternative approach to
fixing this problem (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.
How
SCSI/SATA
> drivers needed on guest?
>
The virtio block driver 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
. Is virtio for the disk supported by kvm-60 and do i need 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".
Regar
7;m
particularly curious 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/vse012
et to the guest supported by the majority 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 exp
trying to boot from it, compare it to a
white list of known bad CDs, and then generate a qcow2 automatically
with gfxboot disabled. When we eventually support big real mode in the
kernel, we can disable this.
[1] http://hg.codemonkey.ws
nnot easily 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 @@ a
gt; ppcemb_kvm-sofmmu target. Along with this is a fake-exec.c 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 tha
need to send out a patch to make virtio_net reset aware
* -net tap is broken for more than 1 network device (at least with virtio)
* QEMU should allow more than 32 PCI devices.
Please try your tests again with -no-acpi and -net user and let me know
if that prevents the problem. Thanks
ier to implement something
similar for ia64 and x86.
> diff --git a/qemu/fake-exec.c b/qemu/fake-exec.c
> new file mode 100644
> --- /dev/null
> +++ b/qemu/fake-exec.c
> @@ -0,0 +1,62 @@
>
Please add a copyright to this file.
Regards,
Anthony Liguori
-
No one else can use it.
> Is everyone else supposed to work then?
>
But your "solution" doesn't fix anyone else. It just causes a broken
build for them :-)
Regards,
Anthony Liguori
>> Regards,
>>
>> Anthony Liguori
>>
>>
>
hing 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.
>
> Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
>
> diff --git a/configure b/config
uest Win2000 this options work fine.
I believe this issue is actually qcow2. With a guest using virtio_blk,
qemu will actually deadlock when using -smp 2/4 when using a qcow disk.
I'm looking into it right now.
Regards,
Anthony Liguori
> My system is:
> CPU: Core2Duo E6400
>
ike
ia64, s390, and even x86). At least ia64 and s390 aren't going to have
functioning translation bits so having a -kvm target really makes a lot
more sense than faking out a -softmmu target.
Regards,
Anthony Liguori
> Another long-term option is to fix TCG for PowerPC upstream, and
hould try to push it for -rc2.
> Anthony, Dor,
> are you ok with that change?
>
Yes.
Acked-by: Anthony Liguori <[EMAIL PROTECTED]>
Regards,
Anthony Liguori
> --
>
> With the latest virtio_reset patches I got the following oops:
>
> Unable to handle ke
pad
structures that are naturally aligned anyway.
Regards,
Anthony Liguori
> struct vring {
> unsigned int num;
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Mi
gt;
This isn't intentional. What is the guest and how does it crash?
I've been using the same image for most of KVM's development life cycle
without having issues.
Regards,
Anthony Liguori
> This is reproducible on Intel (64bit) kernel. Was
o it's not enabled at the moment. It
should be pretty easy to update it though.
This approach would allow -kernel to be used without any disk (which
also solves your problem, but in a different way). We can also
eliminate all the boot sector hijacking silliness.
Regards,
Anthony Ligu
e Linux host is acting to balance out memory in the most appropriate
way to maximize performance. The guest will get as much memory as it
needs until the host system starts getting low on memory.
If you want to know what much of the memory the guest is using, you need
to ask the guest to tell
less easy to
detect.
So what we would like to do, is instead of setting up vm86 mode for the
guest to execute real mode, use x86_emulate() to just emulate the code.
This means that we wouldn't be using the "vmlaunch" instruction when in
real mode and instead would be doing an x86
u're going this route.
However, I still don't think that supporting asymmetric cores is really
useful at the moment and that introducing a per-vm arch ioctl would be
the best approach.
Regards,
Anthony Liguori
---
upport that.
We shouldn't design for any possible thing that anyone could want in the
future, but rather for the things that we actually can see doing.
If you don't think there's a reasonable chance that you'll be attempting
to im
Why do this at the VCPU level? Would you ever want a VM with two VCPUs
with different cores? You could just add a per-VM arch ioctl to set the
core type that has to be issued before any VCPU creates. Then you don't
have to do ugly stuff like calling ioctls from modules.
Regards,
An
U notifiers, not all memory is reclaimable
all the time. Second, reducing the RSS size and free()'ing in the guest
are not related operations.
Regards,
Anthony Liguori
> - Dietmar
>
>
> -
> This SF.net
Izik Eidus wrote:
> On Mon, 2008-02-04 at 09:11 -0600, Anthony Liguori wrote:
>
>> KVM supports more than 2GB of memory for x86_64 hosts. The following patch
>> fixes a number of type related issues where int's were being used when they
>> shouldn't have been
ed to address something with
> cpu_physical_memory_rw() probably related to &TARGET_PAGE_SIZE
> or ~TARGET_PAGE_SIZE,
>
> the fact is that i dont know if it ever fixed anything
>
Thanks, that was my suspicion too.
Regards,
Anthony Liguori
-
Anthony Liguori wrote:
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
For
tate-attributes-to-VGA_STATE_COMMON.patch
>
Yes, I saw your patch on kvm-devel. It came too late to make my series
but it looks like the right thing to do.
Regards,
Anthony Liguori
> /me grumbles about sourceforge's mailing list archive thing completely
> mess
The -daemonize option is too restrictive when using with SDL. It also switches
the working directory to / too early which causes block devices with a relative
path to fail.
The -daemonize option is needed for my regression testing so I've included this
patch in the series.
This patch hasn't chan
Previously, the BIOS would probe the CPUs for SMP guests. This tends to be
very unreliably because of startup timing issues. By passing the number of
CPUs in the CMOS, the BIOS can detect the number of CPUs much more reliably.
Since v1, I've incorporated Fabrice's feedback so this is now a 1-lin
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
For v2 of this patch, I've moved ram_addr
KVM supports the ability to use ACPI to shutdown guests. In order to enable
this requires some fixes to be able to generate the SCI interrupt and the
appropriate plumbing.
This patch hasn't changed since v1.
diff --git a/hw/acpi.c b/hw/acpi.c
index 2669e4e..e21ded0 100644
--- a/hw/acpi.c
+++ b/h
KVM is a Linux interface for providing userspace interfaces for accelerated
virtualization. It has been included since 2.6.20 and supports Intel VT and
AMD-V. Ports are under way for ia64, embedded PowerPC, and s390.
This set of patches provide basic support for KVM in QEMU. It does not include
Hi Izik,
Anthony Liguori wrote:
> Index: qemu/cpu-all.h
> ===
> --- qemu.orig/cpu-all.h 2008-02-01 15:24:45.0 -0600
> +++ qemu/cpu-all.h2008-02-01 15:28:48.0 -0600
> @@ -695,7 +695,7 @@
The -daemonize option is too restrictive when using with SDL. It also switches
the working directory to / too early which causes block devices with a relative
path to fail.
The -daemonize option is needed for my regression testing so I've included this
patch in the series.
This patch hasn't chan
And attached is v2 which updates both uses of ram_size instead of just
the one :-)
Regards,
Anthony Liguori
Anthony Liguori wrote:
This was never corrected during the ram_alloc() conversion.
Index: qemu/hw/pc.c
Avi Kivity wrote:
> From: Avi Kivity <[EMAIL PROTECTED]>
>
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
>
Can you also add one for qemu-kvm-x86.c?
Regards,
Anthony Liguori
-
This SF.n
KVM supports the ability to use ACPI to shutdown guests. In order to enable
this requires some fixes to be able to generate the SCI interrupt and the
appropriate plumbing.
This patch hasn't changed since v1.
Index: qemu/hw/acpi.c
==
Previously, the BIOS would probe the CPUs for SMP guests. This tends to be
very unreliably because of startup timing issues. By passing the number of
CPUs in the CMOS, the BIOS can detect the number of CPUs much more reliably.
Since v1, I've incorporated Fabrice's feedback so this is now a 1-lin
This removes -DCONFIG_X86 and installs asm/kvm.h. Otherwise, it's impossible
to build an application based on a make install of libkvm.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/configure b/configure
index 6b20c2f..418dbea 100755
--- a/configure
+++ b/configu
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
For v2 of this page, I've moved ram_addr_
This was never corrected during the ram_alloc() conversion.
Index: qemu/hw/pc.c
===
--- qemu.orig/hw/pc.c 2008-02-01 10:01:47.0 -0600
+++ qemu/hw/pc.c2008-02-01 10:57:01.0 -0600
@@ -869,7 +869,7 @@
} els
KVM is a Linux interface for providing userspace interfaces for accelerated
virtualization. It has been included since 2.6.20 and supports Intel VT and
AMD-V. Ports are under way for ia64, embedded PowerPC, and s390.
This set of patches provide basic support for KVM in QEMU. It does not include
Daniel P. Berrange wrote:
> On Fri, Feb 01, 2008 at 11:53:02AM -0600, Anthony Liguori wrote:
>
>> Ian Jackson wrote:
>>
>>> Anthony Liguori writes ("[Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use
>>> correct types to enable > 2G support"):
&g
mitation is < 2GB if HOST_BITS==32 or defined(USE_KQEMU).
USE_KQEMU restricts the size of the phys_map which limits the maximum
physical address size. I guess technically USE_KQEMU could allow up to
around 3GB of ram but I preferred to simplify the logic.
Regards,
Anthony Liguori
> Paul
>
Ian Jackson wrote:
> Anthony Liguori writes ("[Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct
> types to enable > 2G support"):
>
>> The alternative is to change all the places that assume phys_ram_base +
>> PA which I don't like very much.
>&
Avi Kivity wrote:
> Anthony Liguori wrote:
>
>> I think I'll change this too into a single qemu_ram_alloc. That will
>> fix the bug with KVM when using -kernel and large memory anyway :-)
>>
>
> Won't that cause all of the memory in the hole to b
Fabrice Bellard wrote:
> Anthony Liguori wrote:
>> +/* above 4giga memory allocation */
>> +if (above_4g_mem_size > 0) {
>> +ram_addr = qemu_ram_alloc(above_4g_mem_size);
>> +cpu_register_physical_memory(0x1, above_4g_mem_size,
>&g
ate to CPUState. We also added some additional state to
CPUState that we need to use.
Other than that, I've removed everything else.
Regards,
Anthony Liguori
> Regards,
>
> Fabrice.
-
This SF.net email
> to handle anything atoi can parse.
>
> As mentioned on IRC, I also noticed that ram_save hasn't been updated.
>
Okay, I'll update both of these.
Regards,
Anthony Liguori
> Paul
>
-
e patch
> Are the CMOS contents documented anywhere?
>
No, but if you have a suggestion of where to document them, I'll add
documentation.
Regards,
Anthony Liguori
> Paul
>
-
This SF.net email is sponsor
Paul Brook wrote:
> On Thursday 31 January 2008, Anthony Liguori wrote:
>
>> KVM supports more than 2GB of memory for x86_64 hosts. The following patch
>> fixes a number of type related issues where int's were being used when they
>> shouldn't have been. It a
FYI, for the new files introduced, Avi should be following up with a
patch to add Copyrights to the files. They will be licensed under the GPL.
Regards,
Anthony Liguori
Anthony Liguori wrote:
> KVM is a Linux interface for providing userspace interfaces for accelerated
> virtualizatio
KVM is a Linux interface for providing userspace interfaces for accelerated
virtualization. It has been included since 2.6.20 and supports Intel VT and
AMD-V. Ports are under way for ia64, embedded PowerPC, and s390.
This set of patches provide basic support for KVM in QEMU. It does not include
KVM requires that any ROM memory be registerd through a second interface. This
patch refactors the option ROM loading to simplify adding KVM support (which
will follow in the next patch).
Index: qemu/hw/pc.c
===
--- qemu.orig/hw/pc.c
KVM supports the ability to use ACPI to shutdown guests. In order to enable
this requires some fixes to be able to generate the SCI interrupt and the
appropriate plumbing.
Index: qemu/hw/acpi.c
===
--- qemu.orig/hw/acpi.c 2008-01-30
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
Index: qemu/cpu-all.h
===
Previously, the BIOS would probe the CPUs for SMP guests. This tends to be
very unreliably because of startup timing issues. By passing the number of
CPUs in the CMOS, the BIOS can detect the number of CPUs much more reliably.
Index: qemu/hw/pc.c
=
The -daemonize option is too restrictive when using with SDL. It also switches
the working directory to / too early which causes block devices with a relative
path to fail.
The -daemonize option is needed for my regression testing so I've included this
patch in the series.
Index: qemu/vl.c
We also have a hard limit for
virtio-pci based on the number of PCI slots available. One thing I was
considering was whether we should try to support multiple disks per
virtio device.
Otherwise, this patch looks good to me.
Regards,
Anthony Liguori
Avi Kivity wrote:
> Anthony Liguori wrote:
>> This removes an unnecessary include of linux/kvm.h which happens to
>> silence
>> a warning introduced by my previous patch :-) We have to move the
>> ABI check
>> too until we've included libkvm.h.
>>
>
vious
patch.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/configure b/configure
index 6b20c2f..418dbea 100755
--- a/configure
+++ b/configure
@@ -94,7 +94,7 @@ fi
#set parameters compiling
if [ "$arch" = "i386" -o "$arch" = "x8
Avi Kivity wrote:
> Anthony Liguori wrote:
>
>> This patch attempts to clean up the interactions between KVM and QEMU. Sorry
>> for such a big patch, but I don't think there's a better way to approach this
>> such that it's still bisect friendly. I thi
This removes an unnecessary include of linux/kvm.h which happens to silence
a warning introduced by my previous patch :-) We have to move the ABI check
too until we've included libkvm.h.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/libkvm/libkvm.c b/libkvm/lib
This patch sucks. Let me finish up playing around with this stuff and
I'll send out a better one.
Regards,
Anthony Liguori
Anthony Liguori wrote:
> This removes an unnecessary include of linux/kvm.h which happens to silence
> a warning introduced by my previous patch :-)
>
&
This removes an unnecessary include of linux/kvm.h which happens to silence
a warning introduced by my previous patch :-)
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/libkvm/libkvm.c b/libkvm/libkvm.c
index d798841..048054b 100644
--- a/libkvm/libkvm.c
+++ b/libkvm/li
vious
patch.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/configure b/configure
index 6b20c2f..418dbea 100755
--- a/configure
+++ b/configure
@@ -94,7 +94,7 @@ fi
#set parameters compiling
if [ "$arch" = "i386" -o "$arch" = "x8
Dor Laor wrote:
> On Mon, 2008-01-28 at 09:32 -0600, Anthony Liguori wrote:
>
>> Hi Dor,
>>
>> How are you measuring performance? The numbers I've gotten with netperf
>> before and after your patch are:
>>
>> tx - 647.27mbit
>> rx - 89.
Avi Kivity wrote:
> Anthony Liguori wrote:
>>
>> PCI-e has a common reset concept (warm and cold). I've been looking
>> around and I can't seem to find any common reset mechanism for PCI.
>> Is FLR something that is per-device or a standard PCI mechanism
Avi Kivity wrote:
> Anthony Liguori wrote:
>>>
>>> I'm worried about the ramp up to 2.6.25 causing confusion among
>>> users as before that things will break left and right, if we don't
>>> provide a tighter check.
>>>
>>
>&g
n't fit into plain qemu just
> yet.
>
In theory, it would still work with QEMU though right? It just requires
a custom guest kernel.
Regards,
Anthony Liguori
> On Sun, 2008-01-27 at 21:46 -0600, Anthony Liguori wrote:
>
>> Jerone Young wrote:
>>
>
Dor Laor wrote:
> On Mon, 2008-01-28 at 09:32 -0600, Anthony Liguori wrote:
>
>> Hi Dor,
>>
>> How are you measuring performance? The numbers I've gotten with netperf
>> before and after your patch are:
>>
>> tx - 647.27mbit
>> rx - 89.
Avi Kivity wrote:
> Anthony Liguori wrote:
>>>
>>> This ABI breakage is worrying. While it is expected to take some
>>> time for the ABI to congeal, we need some way to prevent mismatched
>>> guests and hosts from running. Perhaps something like the
is is the QEMU portion.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/hw/virtio.c b/qemu/hw/virtio.c
index 1e8fb44..78d679f 100644
--- a/qemu/hw/virtio.c
+++ b/qemu/hw/virtio.c
@@ -47,6 +47,9 @@
#define VIRTIO_PCI_CONFIG 20
+/* Virtio ABI version, if w
've been looking
around and I can't seem to find any common reset mechanism for PCI. Is
FLR something that is per-device or a standard PCI mechanism? If it's
the former, than we've basically implemented FLR using this bit in the
config space.
Regards,
Anthony Liguori
e following this part. If add_buf fails, we
notify unconditionally (which is, I think what we want). I'm not sure
how that relates to a packet getting dropped though.
Regards,
Anthony Liguori
-
This SF.net email i
> e of Linux for the Bamboo board. Then run:
>
> ./qemu-system-ppcemb -nographic -M bamboo -kernel cuImage.bambo
>
Since you're just adding a new machine type to the existing ppcemb, it
may be worth while to split out the KVM logic and submi
Avi Kivity wrote:
> Anthony Liguori wrote:
>> This patch updates KVM's virtio implementation to the latest virtio
>> ABI. This
>> includes a change in the network header and support for reset.
>>
>> With this patch, the block and network driver from Rusty
dly and easier-to-find
>
I'm inclined to disagree. Why add an additional thing for people to
tune if they really shouldn't need to. Once NPT/EPT support are stable,
is there any reason to want to disable it?
Regards,
Anthony Liguori
> 2. A lot of people would like to view (
301 - 400 of 1040 matches
Mail list logo
