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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

>  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).

Jan


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