* Avi Kivity <[EMAIL PROTECTED]> wrote:
> > about the 32-bit side: maybe it gives us a bit more options for
> > later if we pick the natural order for 32-bit too: EBX for index,
> > EAX, EDX, ECX for the first 3 parameters, with the remaining 3
> > parameters in ESI, EDI, EBP? Most hypercalls
Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>
>> +/*
>> + * Hypercall calling convention:
>> + *
>> + * RAX is the hypercall index, goes from 0 to __NR_hypercalls-1
>> + *
>> + * Each hypercall may have 0-6 parameters.
>> + *
>> + * parameters 1-6 are in the standard gcc x86_
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> +/*
> + * Hypercall calling convention:
> + *
> + * RAX is the hypercall index, goes from 0 to __NR_hypercalls-1
> + *
> + * Each hypercall may have 0-6 parameters.
> + *
> + * parameters 1-6 are in the standard gcc x86_64 calling convention
> + * order:
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> > so i'd vote for the 64-bit natural register order: return value in
> > rax, parameters in: rdi, rsi, rdx, rcx, r8, r9. On 32-bit that would
> > be edi, esi, edx, ecx, ebx, ebp - the last two shuffled into
> > VCPU_REGS_R8/R9. That's 6 parameters alre
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>>> well, we can standardize on the 32-bit calling convention: eax, ecx,
>>> edx, ebp, etc. We can do that via the 64-bit asm. So it should be the
>>> same i think - just that a 32-bit guest on a 64-bit host wont be able
>>> to
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >well, we can standardize on the 32-bit calling convention: eax, ecx,
> >edx, ebp, etc. We can do that via the 64-bit asm. So it should be the
> >same i think - just that a 32-bit guest on a 64-bit host wont be able
> >to set the high bits of those reg
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>>> Does this look good to you? I'd like the basic API to be as light as
>>> possible.
>>>
>> Won't 32-bit and 64-bit pick different registers?
>>
>> We can work around it (call is_long_mode() when decoding the
>> hypercal
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> > Does this look good to you? I'd like the basic API to be as light as
> > possible.
>
> Won't 32-bit and 64-bit pick different registers?
>
> We can work around it (call is_long_mode() when decoding the
> hypercall), but it kind of defeats the purpos
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
Where is the vmcall exit handler?
>>> in my tree, have not sent the patch yet - first want to combine it
>>> with the cr3 feature to have it tested.
>>>
>>>
>> I'd like it in the final patch.
>
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> NOTE: i have not updated the cr3 patch to the hypercall API yet (hence
> the aliasing bug is not fixed yet), i wanted to get this to you so
> that we can think about the hypercall API.
>
> Right now what i have is only good to test that the VMCALL ins
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >>Where is the vmcall exit handler?
> >>
> >
> >in my tree, have not sent the patch yet - first want to combine it
> >with the cr3 feature to have it tested.
> >
>
> I'd like it in the final patch.
yeah. Right now i have:
patches/kvm-paravirt-h
Ingo Molnar wrote:
> ok, i changed this and i added the SVM patch function too. AMD's VMMCALL
> is 0x0f, 0x01, 0xd9, correct?
>
>
yes.
>> Where is the vmcall exit handler?
>>
>
> in my tree, have not sent the patch yet - first want to combine it with
> the cr3 feature to have it tested.
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >>>+struct kvm_cr3_cache {
> >>>+ struct kvm_cr3_cache_entry entry[KVM_CR3_CACHE_SIZE];
> >>>+ u32 max_idx;
> >>>+};
> >>>
> >>>
> >>This will require an api version bump whenever KVM_CR3_CACHE_SIZE
> >>changes.
> >>
> >>Better to advertise the
Ingo Molnar wrote:
> * Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>>> @@ -237,6 +238,8 @@ struct kvm_vcpu {
>>> unsigned long cr0;
>>> unsigned long cr2;
>>> unsigned long cr3;
>>> + struct kvm_vcpu_para_state *para_state;
>>>
>>>
>> Do we want this as part of kvm_vcpu or k
* Avi Kivity <[EMAIL PROTECTED]> wrote:
> >@@ -237,6 +238,8 @@ struct kvm_vcpu {
> > unsigned long cr0;
> > unsigned long cr2;
> > unsigned long cr3;
> >+struct kvm_vcpu_para_state *para_state;
> >
> Do we want this as part of kvm_vcpu or kvm? I can see arguments for
> both vi
Ingo Molnar wrote:
> Subject: [patch] KVM: add MSR based hypercall API
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> this adds a special MSR based hypercall API to KVM. This is to be used
> by paravirtual kernels and virtual drivers.
>
> VMX-only at the moment.
>
> Signed-off-by: Ingo Molnar <[EMAIL
16 matches
Mail list logo
