Re: [Xen-devel] [PATCH v2 00/11] hvmctl hypercall

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 24/06/16 14:37, Jan Beulich wrote:
>>>> On 24.06.16 at 15:27, <david.vrabel@xxxxxxxxxx> wrote:
>> On 24/06/16 11:35, Jan Beulich wrote:
>>>>>> On 24.06.16 at 12:29, <david.vrabel@xxxxxxxxxx> wrote:
>>>> On 24/06/16 11:21, Jan Beulich wrote:
>>>>> A long while back separating out all control kind operations (intended
>>>>> for use by only the control domain or device model) from the currect
>>>>> hvmop hypercall has been discussed. This series aims at finally making
>>>>> this reality (at once allowing to streamline the associated XSM checking).
>>>>>
>>>>> 01: public / x86: introduce hvmctl hypercall
>>>>> 02: convert HVMOP_set_pci_intx_level
>>>>> 03: convert HVMOP_set_isa_irq_level
>>>>> 04: convert HVMOP_set_pci_link_route
>>>>> 05: convert HVMOP_track_dirty_vram
>>>>> 06: convert HVMOP_modified_memory
>>>>> 07: convert HVMOP_set_mem_type
>>>>> 08: convert HVMOP_inject_trap
>>>>> 09: convert HVMOP_inject_msi
>>>>> 10: convert HVMOP_*ioreq_server*
>>>>> 11: x86/HVM: serialize trap injecting producer and consumer
>>>>
>>>> Is hvmctl going to have a stable ABI?
>>>
>>> No, that's why it is being versioned - just like domctl and sysctl.
>>
>> Isn't this a backward step?
> 
> No. This series merely splits off the unstable portion of HVMOP to a
> separate hypercall.

It's not a forward step either.

>>  Don't we want to be able to (for example)
>> produce qemu stubdom images that aren't tied to specific Xen versions?
> 
> Yes. With libxc sitting in between this is no problem, at least if
> carefully used (see patches 2, 3, and 4  for examples where full
> conversion could not be done because of parts of the unstable
> interface having leaked beyond libxc).

There has been discussion in the past about creating a stable hypervisor
ABI for use by device models (and thus a userspace library with a stable
ABI and API).

Why is this conversion not working towards this?

David

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel