Andy Lutomirski writes ([Xen-devel] [RFC] Hypervisor RNG and enumeration):
Here's a draft CommonHV spec. It's also on github:
https://github.com/amluto/CommonHV
This a worthwhile direction to investigate, and an interesting
proposal. From a Xen point of view I have some concerns, though.
I
Glauber Costa writes ([PATCH] hook cpu running at a higher level.):
This patch removes the kvm_enabled() check from cpu-exec.c.
This file is highly tcg-specific, and we'll probably want it
out when tcg is not compiled in (coming soon, in a theathe near you)
That would be interesting,
Avi Kivity writes (Re: [PATCH] hook cpu running at a higher level.):
kvm is run-time selectable, both in upstream and in kvm-userspace. If
kvm is not detected (or the caller lacks sufficient privileges), we fall
back to tcg (of course we'd also like the option of not compiling tcg
where
Avi Kivity writes (Re: [PATCH] hook cpu running at a higher level.):
I thing it makes sense for you to have multiple vcpus -- that is
multiple CPUState objects. You can still have just one thread (which
would be the iothread in kvm's terminology).
Xen does have multiple vcpus (of course)
Glauber Costa writes (Re: [Qemu-devel] Re: [PATCH] hook cpu running at a
higher level.):
On Tue, Dec 30, 2008 at 8:24 AM, Ian Jackson
The Xen qemu process runs only in one thread which is fine because it
doesn't need to be involved with actual processor execution. In
theory parallel
Avi Kivity writes ([Qemu-devel] Re: [PATCH 2 of 5] add can_dma/post_dma for
direct IO):
Newer Xen shouldn't have this problem though; it runs qemu in kernel
mode in a dedicated 64-bit domain.
This is not yet the default configuration and there are still various
reasons why you might not want
Glauber Costa writes ([Qemu-devel] [PATCH 0/5] Replace tcg memory functions):
This series replaces some of the tcg memory handling functions,
like cpu_physical_memory_rw and cpu_register_physical_memory
by kvm versions.
I believe this approach pays, because it'll reduce the dependency
that
Glauber Costa writes (Re: [Qemu-devel] [PATCH 0/5] Replace tcg memory
functions):
I never stated that you depend on that. We (kvm) don't depend on
that either, but nevertheless, have to live with it. An alternative,
of course, is to heavily patch your qemu tree, providing your own
Anthony Liguori writes:
This patch implements posix-aio using pthreads. It immediately
eliminates the need for fd pooling.
Well in principle I think I approve. Having read the discussion I
think emulation of preadv/pwritev with pread/pwrite is probably fine.
However I did want to make one
Amit Shah writes ([Qemu-devel] Re: [PATCH 1/1] KVM/userspace: Support for
assigning PCI devices to guests):
I got the xen-unstable hg tree and am looking at
tools/ioemu/pass-through.[ch]
That's the old ioemu tree which is pretty much dead now.
Please point me to the code you're looking at.
Anthony Liguori writes (Re: [PATCH 1/1] KVM/userspace: Support for assigning
PCI devices to guests):
Where did this come from originally? It's completely different from
what is in xen-unstable. What's in xen-unstable is actually a lot nicer
IMHO.
Amit: have you taken a look at the code in
Anthony Liguori writes ([Qemu-devel] Re: [PATCH 0/8] Various USB fixes and
improvements (update 2)):
Any objections to applying this series? It seems like the consensus is
that OHCI support is better long term but this series seems pretty sane
and self-contained.
I haven't reviewed the
Daniel P. Berrange writes ([Xen-devel] Re: Announcing: Open OVF project source
code availibility):
Building an XML-RPC
interface just to call into functions for manipulating OVF files is
rather overkill.
Also it is far from clear whether merely changing the concrete
representation of the
13 matches
Mail list logo
