On Thu, Jul 31, 2014 at 10:11 AM, David Vrabel <[email protected]> wrote:
> On 31/07/14 14:53, Ian Campbell wrote:
>> On Thu, 2014-07-31 at 14:16 +0100, Frediano Ziglio wrote:
>>
>>> include/xen/interface/domctl.h | 1090 ++++++++++++++++++++++++++++++++++++
>>
>> domctl is an stable toolstack only hypervisor interface, so the kernel
>> cannot use it because it would then break.
>
> Ok. I guess we'll have to resurrect the idea to do something with XSM.
What kind of thing did you have in mind for XSM?
In general it seems like allowing a vcpu to switch into an XSM label
(not sure I've got the terminology right here) when it context
switches into a particular process might be the most flexible way for
that to work.
But would that actually be easier than implementing stub domains?
-George
On 31/07/14 18:49, George Dunlap wrote:
> On Thu, Jul 31, 2014 at 10:11 AM, David Vrabel <[email protected]> wrote:
>> On 31/07/14 14:53, Ian Campbell wrote:
>>> On Thu, 2014-07-31 at 14:16 +0100, Frediano Ziglio wrote:
>>>
>>>> include/xen/interface/domctl.h | 1090 ++++++++++++++++++++++++++++++++++++
>>>
>>> domctl is an stable toolstack only hypervisor interface, so the kernel
>>> cannot use it because it would then break.
>>
>> Ok. I guess we'll have to resurrect the idea to do something with XSM.
>
> What kind of thing did you have in mind for XSM?
A multicall-like hypercall that has an additional parameter for a handle
to a XSM context to use for the contained hypercalls.
> In general it seems like allowing a vcpu to switch into an XSM label
> (not sure I've got the terminology right here) when it context
> switches into a particular process might be the most flexible way for
> that to work.
I think we want something than can a different policy on a per-fd basis.
David