Richard Henderson (6):
Move TARGET_PHYS_ADDR_SPACE_BITS to target-*/cpu.h.
Use TARGET_VIRT_ADDR_SPACE_BITS in h2g_valid.
linux-user: Use h2g_valid in qemu_vmalloc.
linux-user: Fix mmap_find_vma returning invalid addresses.
Implement multi-level page tables.
Fix last page errors
/src/qemu/exec.c: In function `page_set_flags':
/src/qemu/exec.c:2336: warning: comparison is always true due to
limited range of data type
Should be fixed by b480d9b74dfd1efd29026b7dc6438364a633ee99
Paul
a) elfload.c:859
#define TARGET_ELF_PAGESTART(_v) ((_v) ~(unsigned
long)(TARGET_ELF_EXEC_PAGESIZE-1))
This means that for 64bit guest on a 32bit host the _v's value is
silently reduced to 32bit, the cast should be abi_ulong.
b) mmap.c:428
real_start = start
On 03/10/2010 07:41 PM, Paul Brook wrote:
You're much better off using a bulk-data transfer API that relaxes
coherency requirements. IOW, shared memory doesn't make sense for TCG
Rather, tcg doesn't make sense for shared memory smp. But we knew that
already.
In think TCG SMP
+struct QEMUNotifier
+{
+void (*notify)(QEMUNotifier *notifier);
+};
I suggest combining this with QEMUBH.
Paul
On 03/11/2010 01:57 PM, Paul Brook wrote:
+struct QEMUNotifier
+{
+void (*notify)(QEMUNotifier *notifier);
+};
I suggest combining this with QEMUBH.
I didn't understand this suggestion exactly, but I think it's related
that I didn't understand the advantage of making
On 03/11/2010 06:57 AM, Paul Brook wrote:
+struct QEMUNotifier
+{
+void (*notify)(QEMUNotifier *notifier);
+};
I suggest combining this with QEMUBH.
I take it your not opposed to converting QEMUBH to be a QEMUNotifier?
If so, I'm happy to do it.
It's unclear to me why you've
+ /*
+* Align on HPAGE_SIZE so (gfn ^ pfn)
+* (HPAGE_SIZE-1) == 0 to allow KVM to take advantage
+* of hugepages with NPT/EPT.
+*/
+ new_block-host = qemu_memalign(1 TARGET_HPAGE_BITS, size);
This should not be
Paul Brook wrote:
Is there any reason (other than being coding style) in using
qemu_free() instead of free()? As per qem-malloc.c qemu_free() is
nothing but free().
The whole point of qemu_{malloc,free} is to isolate code from the system
implementation of malloc/free. It's entirely
On Thu, Mar 11, 2010 at 04:28:04PM +, Paul Brook wrote:
+ /*
+* Align on HPAGE_SIZE so (gfn ^ pfn)
+* (HPAGE_SIZE-1) == 0 to allow KVM to take advantage
+* of hugepages with NPT/EPT
Is there any reason (other than being coding style) in using qemu_free()
instead of free()? As per qem-malloc.c qemu_free() is nothing but free().
The whole point of qemu_{malloc,free} is to isolate code from the system
implementation of malloc/free. It's entirely possible that future
On 02/26/2010 10:17 AM, Gerd Hoffmann wrote:
Adds infrastructure for keyboard led status tracking to qemu.
Signed-off-by: Gerd Hoffmannkra...@redhat.com
Applied. Thanks.
What about guests that use the capslock LED for something useful, instead of
capslock?
Paul
In a cross environment that becomes extremely hairy. For example the x86
architecture effectively has an implicit write barrier before every
store, and an implicit read barrier before every load.
Btw, x86 doesn't have any implicit barriers due to ordinary loads.
Only stores and atomics
On 03/08/2010 12:53 AM, Paul Brook wrote:
Support an inter-vm shared memory device that maps a shared-memory
object as a PCI device in the guest. This patch also supports
interrupts between guest by communicating over a unix domain socket.
This patch applies to the qemu-kvm repository
However, coherence could be made host-type-independent by the host
mapping and unampping pages, so that each page is only mapped into one
guest (or guest CPU) at a time. Just like some clustering filesystems
do to maintain coherence.
You're assuming that a TLB flush implies a write barrier,
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
usb-linux.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index a9c15c6..23155dd 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -846,9 +846,6 @@ static int
Support an inter-vm shared memory device that maps a shared-memory object
as a PCI device in the guest. This patch also supports interrupts between
guest by communicating over a unix domain socket. This patch applies to
the qemu-kvm repository.
No. All new devices should be fully qdev
On Fri, Mar 05, 2010 at 11:15:45AM +, Paul Brook wrote:
TCG internal helpers only access to the values passed in arguments, and
do not modify the CPU internal state. Thus they can be declared as
const and pure.
I think this needs an explanatory comment. It's not immediately
TCG internal helpers only access to the values passed in arguments, and
do not modify the CPU internal state. Thus they can be declared as
const and pure.
I think this needs an explanatory comment. It's not immediately obvious that
tcg_gen_helperN and tcg_gen_helper{32,64} have significantly
That sounds like it's likely to come back and bite you. The guest has no
idea which areas of ram happen to be contiguous on the host.
Practically speaking, with target-i386 anything that is contiguous in
guest physical memory is contiguous in the host address space provided
it's ram.
I think this assumption is unsafe. There are machines where RAM mappings
can change. It's not uncommon for a chip select (i.e. physical memory
address region) to be switchable to several different sources, one of
which may be RAM. I'm pretty sure this functionality is present (but not
With a new api, cpu_physical_memory_map() changes semantics. It only
returns pointers for static ram mappings. Everything else is bounced
which guarantees that an address can't change during DMA.
Doesn't this mean that only the initial RAM is directly DMA-able?
While memory
I want to port QEMU on the ARM11 platform. I think, many developers try to
this work.
Should already work.
Paul
The key difference is that these regions are created and destroyed
rarely and in such a way that the destruction is visible to the guest.
So you're making ram unmap an asynchronous process, and requiring that
the address space not be reused until that umap has completed?
It
The new function I'm proposing has the following semantics:
- it always returns a persistent mapping
- it never bounces
- it will only fail if the mapping isn't ram
So you're assuming that virtio rings are in ram that is not hot-pluggable or
remapable, and the whole region is contiguous?
On 02/26/2010 07:32 PM, Paul Brook wrote:
You could still use them for local register variables, but I can
prepare a patch to remove them (unless you do that yourself).
I'm not sure what you mean by a local register variable.
I'm thinking of using
register blah blah asm(AREG1
ARMv7 has a simplified access permissions model that is enabled
by setting the AFE bit of the SCTLR. This patch adds checking
for permission values for when this mode is selected.
This is already implemented.
Paul
There certainly
exist machines that can change physical RAM mapping.
I am talking about mapping between phy RAM offset and qemu virt address.
When can it change without RAM in question going away?
RAM offset or guest physical address? The two are very different.
Some machines have chip
invalid/unsupported opcode: 00 - 00 - 00 () 4800fa44 1
I have fixed that in HEAD by stopping the translation just after a trap,
as the instructions might never be executed.
It is not a full fix, as the OS can actually use any instruction that
always generate a trap (even a memory
/* All direct uses of g2h and h2g need to go away for usermode softmmu.
*/ #define g2h(x) ((void *)((unsigned long)(x) + GUEST_BASE))
+
+#if HOST_LONG_BITS == TARGET_VIRT_ADDR_SPACE_BITS
Shouldn't this be = ?
1ul T_V_A_S_B is undefined for 64-bit guests on 32-bit hosts.
+#define
So guest can cause vhost to write to a wrong place in RAM, but it can
just pass a wrong address directly.
That's not the point. Obviously any DMA capable device can be used to
compromise a system. However if a device writes to address B after being told
to write to address A, then you have
I'm sympathetic to your arguments though. As qemu is today, the above
is definitely the right thing to do. But ram is always ram and ram
always has a fixed (albeit non-linear) mapping within a guest.
I think this assumption is unsafe. There are machines where RAM mappings can
change. It's
Which brings us to the problem of exec.c and the address spaces therein.
First, there was the fact that TARGET_PHYS_ADDR_SPACE_BITS was constrained
to be no larger than 32 (with a partial hack for Alpha to extend this to
42 bits). Second, that this physical address space value was applied to
Since virtio devices can live on two busses (sysbus with Syborg or PCI),
we need to introduce a set of virtio specific functions.
...
Inside the VirtIODevice, there would be corresponding function pointers,
and depending on whether it was a PCI device or a Syborg device, it would
call
diff --git a/qemu-lock.h b/qemu-lock.h
This code isn't used in any interesting ways, it should be removed..
Paul
+/*
+ * ftruncate is not supported by hugetlbfs in older
+ * hosts, so don't bother checking for errors.
+ * If anything goes wrong with it under other filesystems,
+ * mmap will fail.
+ */
+if (ftruncate(fd, memory))
+ perror(ftruncate);
Code does not match
Use led status notification support in vnc.
The qemu vnc server keeps track of the capslock and numlock states based
on the key presses it receives from the vnc client. But this fails in
case the guests idea of the capslock and numlock state changes for other
reasons. One case is guest
On 02/25/10 11:23, Markus Armbruster wrote:
You're supposed to use scsi-generic for that. Which rejects anything
but /dev/sg*.
Well, it isn't *that* easy. The SG_IO ioctl used by scsi-generic works
on tons of devices in linux, not only /dev/sg*. I've seen patches
floading around which
I'm pretty sure a guest can cause those to change and I'm not 100%
sure, but I think it's a potential source of exploits if you assume a
mapping. In the very least, a guest can trick vhost into writing to ram
that it wouldn't normally write to.
This seems harmless. guest can write
Since b567b38 (target-arm: remove T0 and T1, 2009-10-16) the only global
register that is actually used is AREG0, so the complexity of
hostregs_helper.h is unwarranted.
Let's just say that env should be the only global register. AREG1 and
AREG2 in principle could still be used to work
On 02/26/2010 12:30 PM, Paul Brook wrote:
Since b567b38 (target-arm: remove T0 and T1, 2009-10-16) the only global
register that is actually used is AREG0, so the complexity of
hostregs_helper.h is unwarranted.
Let's just say that env should be the only global register. AREG1
Before doing the switch, I need to figure out what to do with the
current texi documentation. I think it makes sense to move
qemu-doc.texi to a wiki page and remove it from the source repository.
The other option would be to link to it as an external page and keep it
within revision control.
+++ b/hw/rtl8139.c
@@ -41,6 +41,10 @@
* segmentation offloading
* Removed slirp.h dependency
* Added rx/tx buffer reset when enabling
rx/tx operation + *
+ * 2010-Feb-04 Frediano
Idle bottom halves (i.e. qemu_bh_schedule_idle) are just bugs waiting to
happen, and should never be used for anything.
Idle bottom halves make considerable more sense than the normal bottom
halves.
The fact that rescheduling a bottom half within a bottom half results in
an infinite
Very simply, without idle bottom halves, there's no way to implement
polling with the main loop. If we dropped idle bottom halves, we would
have to add explicit polling back to the main loop.
How would you implement polling?
AFAICS any sort of polling is by definition time based so use a
On Wed, Feb 24, 2010 at 03:14:25AM +, Paul Brook wrote:
vnet_hdr is IMHO a really bad example to copy from.
vnet_hdr leaks into the migration state via n-has_vnet_hdr. What this
means is that if you want to migrate from -net tap -net
nic,model=virtio to -net user -net nic
I suggest these steps:
1. Debug output to stdout is no longer accepted for new / modified code.
2. New or modified debug messages should go to stderr.
I don't see this as a real improvement. Arguably these aren't errors, so
stdout is where they should be going.
If we're going to do
Bottom halves are run at the very end of the event loop which means that
they're guaranteed to be the last thing run. idle bottom halves can be
rescheduled without causing an infinite loop and do not affect the
select timeout (which normal bottom halves do).
Idle bottom halves (i.e.
vnet_hdr is IMHO a really bad example to copy from.
vnet_hdr leaks into the migration state via n-has_vnet_hdr. What this
means is that if you want to migrate from -net tap -net nic,model=virtio
to -net user -net nic,model=virtio, it will fail.
This is a hard problem to solve in qemu
On Tuesday 12 January 2010, Isaku Yamahata wrote:
To use pci host framework, use PCIHostState instead of PCIBus in
PCIVPBState.
No.
pci_host.[ch] provides very specific functionality, it is not a generic PCI
host device. Specifically it provides indirect access to PCI config space via
a
I thought we will get rid of vpb_pci_config_addr, and fill in
fields in PCIConfigAddress directly. If we don't, and still
recode into PC format, this is not making code any prettier
so I don't really see what this buys us.
I agree. This patch seems to be introducing churn for no benefit.
The problem is that the whole define is just plain wrong which tells me
that the code is using the bswap functions incorrectly. This really
needs to be fixed by someone who knows the dbdma device. I don't see how
calling incorrect calls even more incorrect makes any difference.
The real
So possibly this means that we
could optimize the barrier away, but I don't think this amounts to a
serious issue, I guess portability/readability is more important.
The more important issue is that regular devices which to not require
coherency or ordering can omit this lock.
So
On Wednesday 23 December 2009, Michael S. Tsirkin wrote:
On Wed, Dec 23, 2009 at 12:25:46PM +, Paul Brook wrote:
So possibly this means that we
could optimize the barrier away, but I don't think this amounts to
a serious issue, I guess portability/readability is more important
Given we need both, why not actually defined an API that gives you
this?
Because, I do not want to define APIs, I want to reuse an existing one.
Except that, say you said later in your email, no API exists for doing
atomic accesses, so you need different code anyway.
Did I
http://thread.gmane.org/gmane.comp.emulators.qemu/44869
I'm not sure why Paul never pushed it but I think he was able to create
the syborg board purely from a device tree.
The patches referenced above include purely device-tree based Syborg and
Stellaris boards.
It works fairly nicely for
We should just qemu_ram_alloc() that memory regardless of whether we
every map it into the guest. Since roms can be large, we want to send
their contents over during the live part of migration. If we use
qemu_ram_alloc(), we get that for free.
Currently live migration uses ram_addrs,
Ram allocations should be associated with a device. The VMState stuff
this should make this fairly straightforward.
Right, but for the sake of simplicity, you don't want to treat that ram
any differently than main ram wrt live migration. That's why I proposed
adding a context id for each
On Tuesday 22 December 2009, Anthony Liguori wrote:
On 12/22/2009 05:26 AM, Michael S. Tsirkin wrote:
On Tue, Dec 08, 2009 at 06:18:18PM +0200, Michael S. Tsirkin wrote:
The following fixes a class of long-standing bugs in qemu:
when kvm is enabled, guest might access device structures
in
Given this is supposed to be portable code, I wonder if we should have
atomic ordered memory accessors instead.
Paul
Could you clarify please?
The infiniband bits I used as base are very portable,
I know they build on a ton of platforms. I just stripped
a couple of infiniband
On Saturday 19 December 2009, Richard Henderson wrote:
Changes from round 3:
* Drop movcond for now.
* Only use movzbl and not xor in setcond.
I'm still catching up on mail backlog from this thread, but I'm concerned that
we're exposing setcond to the target translation code if we're
--- a/posix-aio-compat.c
+++ b/posix-aio-compat.c
@@ -502,7 +502,8 @@ static void aio_signal_handler(int signum)
if (posix_aio_state) {
char byte = 0;
- write(posix_aio_state-wfd, byte, sizeof(byte));
+ if (write(posix_aio_state-wfd, byte, sizeof(byte)) != sizeof(byte))
+
On Saturday 12 December 2009, Dave Airlie wrote:
So I've been musing on the addition of some sort of 3D passthrough for
qemu (as I'm sure have lots of ppl)
IIUC a typical graphics system consists of several operations:
1) Allocate space for data objects[2] on server[1].
2) Upload data from
-uint32_t VF; /* V is the bit 31. All other bits are undefined */
+uint32_t VF; /* V is the bit 28. */
No. The original comment is correct.
Paul
According to comment in exec-all.h:
/* Deterministic execution requires that IO only be performed on the last
instruction of a TB so that interrupts take effect immediately. */
Sparc generator must then violate this assumption. Is the assumption
valid also when not using icount and
On Thursday 10 December 2009, Michael S. Tsirkin wrote:
The recent e1000 bug made the important of using
symbolic macros for pci config access clear for me.
So I started going over drivers and converting
to symbolic constants instead of hard-coded ones.
I did a large part until I run out of
On Monday 07 December 2009, Artyom Tarasenko wrote:
Can it be that qemu (-system-sparc in my case, but I guess it's more
or less similar on all platforms) reacts to irqs slower than a real
hardware due to tcg optimizations?
Interrupts generally only trigger at branch instructions, or similar.
type *qemu_new(type, n_types);
type *qemu_new0(type, n_types);
type *qemu_renew(type, mem, n_types);
type *qemu_renew0(type, mem, n_types);
It always annoys me having to specify element count for things that aren't
arrays.
I suggestion a single object allocation function, and an array
Using -icount should give you precise interrupt delivery.
That's what I thought, but as I reported a few days ago, I couldn't
find a good value for icount when using OBP.
I tried a few values but keep getting qemu: fatal: Raised interrupt
while not in I/O function.
That's almost certainly
On Monday 30 November 2009, Alexander Graf wrote:
Currently we have this stupid role of disallowing:
if (r)
break;
This has been discussed to death several times, in several different paces,
and with no clear resolution or consensus, so I'm going to make an executive
decision:
The
Our cpu keeps multiple seperate address spaces open at the same time
(similar to x86 with a bunch of cr0s), defined by address space control
elements in various control registers. Linux uses primary, secondary and
home space to address user space and kernel space. The third one is user
You might want to have a 'static uint8_t zero_length_malloc[0]' and
return that instead of the magic cookie '1'. Makes the code more
readable IMHO and you'll also have symbol in gdb when debugging qemu.
Having multiple malloc return the same pointer sounds like a really bad idea.
Paul
On Tuesday 01 December 2009, Glauber Costa wrote:
On Tue, Dec 01, 2009 at 12:57:27PM +, Paul Brook wrote:
You might want to have a 'static uint8_t zero_length_malloc[0]' and
return that instead of the magic cookie '1'. Makes the code more
readable IMHO and you'll also have symbol
No, this would slow us down because these are per-pin.
We need a sum of interrupts so that config space
can be updated by a single command.
Interrupts are a fastpath, extra loops there should be avoided.
It's really not that much of a fast path. Unless you're doing something
particularly
It's really not that much of a fast path. Unless you're doing something
particularly obscure then even under heavy load you're unlikely to exceed
a few kHz.
I think with kvm, heavy disk stressing benchmark can get higher.
I'd still expect this to be the least of your problems.
If nothing
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -30,8 +30,7 @@
#include softfloat.h
-#define NB_MMU_MODES 2 // guess
-#define MMU_USER_IDX 0 // guess
+#define NB_MMU_MODES 2
The fact that you're modifying a file you added earlier in the same patch
series gives me very little
So maybe add use -device ? to get list of all devices
to help text?
[...@tuck qemu]$ ~/qemu-git/bin/qemu-system-x86_64 -device ?
/home/mst/qemu-git/bin/qemu-system-x86_64: invalid option -- '-device'
You need to stop your shell eating the ?
Paul
But it's easy to support migration to old qemu just
by discarding the INTx state, and this is not
at all harder, or worse, than migrating from old qemu
to new one.
Do we really care about migrating to older versions?
Migrating to a new version (backward compatibility) I see the use, it
On Tuesday 24 November 2009, Gerd Hoffmann wrote:
On 11/16/09 19:53, Paul Brook wrote:
Capping the amount of memory required for a transfer *is* implemented, in
both LSI and virtio-blk. The exception being SCSI passthrough where the
kernel API makes it impossible.
Well. Figured while
Reading in old state files is a whole lot easier (to write
maintain, and stay sane) than producing state that is bug-compatible with
previous versions.
It seems to me that old-new and new-old migrations are
of about the same level of difficulty.
Supporting one of these but not the other
On Monday 23 November 2009, Gerd Hoffmann wrote:
On 11/20/09 18:41, Paul Brook wrote:
On Tuesday 17 November 2009, Gerd Hoffmann wrote:
Add a greeting string to CharDriverState which is printed after
initialization. Used to have the qemu vc consoles labeled. This
way we can avoid
On Monday 23 November 2009, Gerd Hoffmann wrote:
On 11/23/09 14:26, Paul Brook wrote:
I thinking more that this should be done by the character backend itself.
For example, the graphical consoles should probably be putting this as
part of the window title
Doesn't work with vnc.
That's
On Sunday 22 November 2009, Stefan Weil wrote:
All files config-devices.mak are copies from files in
directory default-configs.
See commit a992fe3, specifically make defconfig.
Paul
That's an option, basically keeping the list (or only one ?) of aliased
TCG variables for each of them, and freeing the others before using one.
Yeah, only one. I don't think this should be getting overengineered (and
thus slow) :-).
Doesn't really sound hard, does it? Any TCG magicians
It would require a mechanism to do enumeration and identification
though.
Huh? Do you want export *all* block devices via extboot? Will IDE
drives show up twice then?
No, because SeaBIOS already has an ATA driver so we wouldn't want to
expose IDE on the extboot bus.
SeaBIOS
move scsi command from SCSIGenericReq to SCSIRequest.
Why? AFAICS This has precisely one user, and more importantly it is not
populated by scsi-disk.c.
Sharing common code is good. Implementing shared fields inconsistently or
putting implementation specific fields in common structures.
Paul
add xfer mode
This should also be used by scsi-disc.c
Paul
On Tuesday 17 November 2009, Gerd Hoffmann wrote:
Changes:
* Move from open-coded lists to QTAILQ macros.
* Move the struct elements to the common data structures
(SCSIDevice + SCSIRequest).
* Fix request cleanup in the destroy callback.
This feels like the abstraction boundaries
The practical example below will explain it completely:
1) we take 4 common modern computers - CoreQuad + 8 GB Memory.
2) we assemble a standard Linux cluster with 16 cores and 32G memory.
3) and now - we run the only one virtual guest system, but give it ALL
available resources.
If
On Tuesday 17 November 2009, Christoph Hellwig wrote:
The subject is a bit confusing - it's not the full request parsing but
just some helpers.
This is a good example of a patch with an insufficient commit message.
Given the way GIT treats the first line of the commit mesaage, my advice is to
In fact I'd much prefer to see extboot rewritten to just virtio-block.
Hmm, I'd prefer something which is *not* used by the guest OS, so it is
a pure bootloader thing. When using it to boot from scsi you don't want
to have the disk show up twice (as virtio and scsi) in the guest.
You're
On Tuesday 17 November 2009, Ian Molton wrote:
Hi,
Qemu currently is making a bit of a hash of parsing suffixes,
Right now, it has:
T, G, M, and K which are multiples of 1024 bytes - fair enough
but it also has:
k - 1024 (should be 1000)
and b:
Byte (also wrong)
since
On Tuesday 17 November 2009, Gerd Hoffmann wrote:
On 11/17/09 13:36, Paul Brook wrote:
In fact I'd much prefer to see extboot rewritten to just virtio-block.
Hmm, I'd prefer something which is *not* used by the guest OS, so it is
a pure bootloader thing. When using it to boot from scsi
Why aren't you also using this function in scsi- disc.c? Surely that's the
whole point of moving it into common code.
Same as with the command move: next patch series will rework scsi-disk
to put the new fields and functions into use.
Hmm, maybe you need to rethink your patch sequencing
While sync appears attractive as a quick hack to achieve this, I think it
is liable to be abused, and cause us serious pain long-term. If you need
an easy solution then use ld/st (as with ARM VFP registers). If you want
a good solution then fix whichever bit of TCG makes accessing a pair
On Monday 16 November 2009, Gerd Hoffmann wrote:
On 11/11/09 17:38, Paul Brook wrote:
That cap is important.
For scsi-generic you probably don't have a choice because of the way
the kernel interface works.
Exactly. And why is the cap important for scsi-disk if scsi-generic
does fine
On Wednesday 11 November 2009, Anthony Liguori wrote:
Hannes Reinecke wrote:
But why? Why do we have to emulate the entire HBA for the BIOS?
The HBA is emulated, too, and just uses the bdrv interface
internally anyway.
So IMHO it makes far more sense to skip the HBA emulation in
the
The current qemu code *does* cache the response. scsi-disk caps the
buffer at 128k (which is big enough for any request I've seen in my
testing). scsi-generic has no cap.
That cap is important.
For scsi-generic you probably don't have a choice because of the way the
kernel interface works.
On Wednesday 11 November 2009, Michael S. Tsirkin wrote:
On Wed, Nov 11, 2009 at 01:45:35PM +, Paul Brook wrote:
If you don't need real barriers, then why does the kvm code have them?
We need real barriers but AFAIK kvm does not have them :(
IOW: virtio is currently broken with kvm
On Wednesday 11 November 2009, Michael S. Tsirkin wrote:
On Wed, Nov 11, 2009 at 02:16:00PM +, Paul Brook wrote:
On Wednesday 11 November 2009, Michael S. Tsirkin wrote:
On Wed, Nov 11, 2009 at 01:45:35PM +, Paul Brook wrote:
If you don't need real barriers, then why does the kvm
501 - 600 of 1522 matches
Mail list logo
