[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 05 May 2009 17:00:22 +0300
From: Avi Kivity <avi@...hat.com>
To: Gregory Haskins <ghaskins@...ell.com>
CC: linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] generic hypercall support
Gregory Haskins wrote:
> Avi Kivity wrote:
>
>> Gregory Haskins wrote:
>>
>>> (Applies to Linus' tree, b4348f32dae3cb6eb4bc21c7ed8f76c0b11e9d6a)
>>>
>>> Please see patch 1/3 for a description. This has been tested with a KVM
>>> guest on x86_64 and appears to work properly. Comments, please.
>>>
>>>
>> What about the hypercalls in include/asm/kvm_para.h?
>>
>> In general, hypercalls cannot be generic since each hypervisor
>> implements its own ABI.
>>
> Please see the prologue to 1/3. Its all described there, including a
> use case which I think answers your questions. If there is still
> ambiguity, let me know.
>
>
Yeah, sorry.
>> The abstraction needs to be at a higher level (pv_ops is such a level).
>>
> Yep, agreed. Thats exactly what this series is doing, actually.
>
No, it doesn't. It makes "making hypercalls" a pv_op, but hypervisors
don't implement the same ABI.
pv_ops all _use_ hypercalls to implement higher level operations, like
set_pte (probably the only place set_pte can be considered a high level
operation).
In this case, the higher level event could be
hypervisor_dynamic_event(number); each pv_ops implementation would use
its own hypercalls to implement that.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists