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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 24/06/16 15:25, Jan Beulich wrote:
>>>> On 24.06.16 at 15:51, <david.vrabel@xxxxxxxxxx> wrote:
>> 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.
> 
> Well - depends on what is relevant to you. It's not a step forward
> for the one aspect you mention. The consolidation XSM-wise, otoh,
> is a step forward imo.
> 
>>>>  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).
> 
> The two are really mostly independent: A properly designed user
> mode library interface can shield against any changes in the
> underlying hypervisor ABI. I don't see what this has to do with this
> series - that's entirely a tool stack thing. (After all the instability
> doesn't have to go as far as subops disappearing all of the sudden;
> it may well just mean tweaks to the existing interface.)
> 
>> Why is this conversion not working towards this?
> 
> Because that wasn't the intention? I have to admit I don't
> understand your questions: As said elsewhere in the discussion
> of this series, this is not a result of IanC's outlining of a stable
> ABI for qemu to use; instead the work item this removed from
> my todo list was a much older one (which, as it happens, also
> resulted from a discussion with IanC).

Yes -- I looked back over the discussion we had last year internally
about the deprivileged qemu, and a lot of this work was spoken of at
that time as a clean-up which had already been desired in its own right.

 -George


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