On Sat, May 03, 2008 at 08:47:17PM +0300, Adrian Bunk wrote:
> Commit c45a6816c19dee67b8f725e6646d428901a6dc24
> (virtio: explicit advertisement of driver features)
> and commit e976a2b997fc4ad70ccc53acfe62811c4aaec851
> (s390: KVM guest: virtio device support, and kvm hypercalls)
> don't like each
> What you've done with dup_mm() is probably the brute-force way that I
> would have done it had I just been trying to make a proof of concept or
> something. I'm worried that there are a bunch of corner cases that
> haven't been considered.
>
> What if someone else is poking around with ptrace o
On Fri, Mar 21, 2008 at 03:33:29PM +0100, Carsten Otte wrote:
> Am Freitag, den 21.03.2008, 15:06 +0100 schrieb Heiko Carstens:
> > Just introduce something like MACHINE_FLAG_KVM. The rest can be converted
> > later. Unless you're bored and feel like fiddling aroun
On Fri, Mar 21, 2008 at 12:12:04PM +0100, Carsten Otte wrote:
> [EMAIL PROTECTED] wrote:
>> Since when do we have symbolic names for the bits?
>> It was always on my todo list to do a cleanup and replace the numbers
>> we use everywhere with names. Especially since we have clashes from time
>> to t
On Thu, Mar 20, 2008 at 09:59:32PM +0100, Carsten Otte wrote:
> Christoph Hellwig wrote:
> > On Thu, Mar 20, 2008 at 09:37:19PM +0100, Carsten Otte wrote:
> >> Christoph Hellwig wrote:
> >>> On Thu, Mar 20, 2008 at 05:25:26PM +0100, Carsten Otte wrote:
> @@ -143,6 +143,10 @@ static noinline __
On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
> KVM is due to receive support for multiple architectures (ppc, ia64, and
> s390, in addition to the existing x86), hopefully in time for the 2.6.25
> merge window. It is awkward to place the new arch support in drivers/kvm/,
> so I'd
> The only thing remotely relevant in the list config is that 'Filter out
> duplicate messages to list members (if possible)' is set as a default for
> new members. Maybe this means that if a cc is also part of the list, that
> cc is stripped (which seems a wierd implementation; I'd have ex
On Thu, May 24, 2007 at 03:10:12PM +0300, Avi Kivity wrote:
> This defines on_one_cpu() which is similar to smp_call_function_single()
> except that it works if cpu happens to be the current cpu. Can also be
> seen as a complement to on_each_cpu() (which also doesn't treat the
> current cpu specia
> Nested page tables/extended page tables also provide this facility, with
> some caveats:
>
> - on 32-bit hosts (or 64-bit hosts with 32-bit userspace), host
> userspace virtual address space is not enough to contain the guest
> physical address space.
> - there is no way to protect the host u
> > We intend to move to a common arch-independent kernel interface and
> > userspace with kvm.
> The address space and vcpu management are rather different from kvm's,
> however your approach is better and we'll want to move kvm in your
> direction rather than the other way round (specifically the
> To investigate PowerPC support I did some work to refactor the KVM code
> into x86 vs shared bits. It was based on the in-kernel KVM code, so I need
> to rebase that work on kvm.git. I guess you guys have the same
> problem; have you done any work in that area?
We haven't done anything yet to ma
On Fri, Apr 27, 2007 at 06:53:40PM +0200, Arnd Bergmann wrote:
> On Friday 27 April 2007, Carsten Otte wrote:
> > Add interface which allows a process to start a virtual machine.
>
> Looks pretty good to me already.
>
> It seems a lot closer to lguest than to kvm at the moment concerning
> the ke
> >For example, lets says you are running several guests, and would like
> to
> >start yet another one for a while - but have no free memory left.
> >
>
> We have another solution for it that will soon be pushed into the
> kernel:
> It is the balloon driver solution.
> Each guest runs a balloon dr
On Mon, Mar 19, 2007 at 06:02:57PM +0200, Avi Kivity wrote:
> Heiko Carstens wrote:
> I agree with all of the above, and in addition, integration to the
> scheduler will allow us to reduce vcpu migration rate, and maybe do
> things like gang scheduling.
>
> But that doesn
On Sun, Mar 18, 2007 at 12:42:00PM +0200, Avi Kivity wrote:
> Heiko Carstens wrote:
> >In addition, if we would port kvm to s390, then we would need to
> >make sure that each virtual cpu only gets executed from the thread
> >that created it. That is simply because the u
On Sun, Mar 18, 2007 at 07:20:57AM +0200, Avi Kivity wrote:
> Heiko Carstens wrote:
> >On Sun, Mar 11, 2007 at 03:53:12PM +0200, Avi Kivity wrote:
> >
> >>This patchset updates the kvm userspace interface to what I hope will
> >>be the long-term stable interf
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index 747966e..376538c 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -2416,6 +2416,12 @@ static long kvm_dev_ioctl(struct file *filp,
> r = 0;
> break;
> }
> + case KVM
On Fri, Mar 16, 2007 at 09:03:08AM -0500, Anthony Liguori wrote:
> Heiko Carstens wrote:
> >On Sun, Mar 11, 2007 at 03:53:12PM +0200, Avi Kivity wrote:
> >
> >>This patchset updates the kvm userspace interface to what I hope will
> >>be the long-term stable in
On Sun, Mar 11, 2007 at 03:53:12PM +0200, Avi Kivity wrote:
> This patchset updates the kvm userspace interface to what I hope will
> be the long-term stable interface. Provisions are included for extending
> the interface later. The patches address performance and cleanliness
> concerns.
Search
19 matches
Mail list logo
