Re: [PATCH v2 00/11] hvmctl hypercall

["Jan Beulich" <JBeulich@suse.com>]

>>> On 24.06.16 at 15:51, <david.vrabel@citrix.com> wrote:
> On 24/06/16 14:37, Jan Beulich wrote:
>>>>> On 24.06.16 at 15:27, <david.vrabel@citrix.com> wrote:
>>> On 24/06/16 11:35, Jan Beulich wrote:
>>>>>>> On 24.06.16 at 12:29, <david.vrabel@citrix.com> 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).

And then - what's your expectation? Any parts of this new
interface can subsequently be marked stable if we so wish. I
don't see why this needs to happen right away.

As to secure usability with a deprivileged qemu (stubdom or
otherwise), without any investigation as to whether the
_implementation_ of those operations actually permits them
being marked so I don't think this can reasonable be stated. And
the auditing required to be certain here is a whole big separate
work item.

Jan


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