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.
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 proce
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
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
> whe
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, certa
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
> implem
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
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 wa
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 c
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 a
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 cod
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 th
13 matches
Mail list logo
