Re: [Xen-users] [Xen-devel] Questions about PVH in Xen 4.3 unstable

[tech mailinglists <mailinglists.tech@xxxxxxxxx>]

Thats good that I understood now everything. So can xenstored/oxenstored stubdoms run on the actual stable trunk? I already talked with Daniel de Graaf from the NSA about this theme in this thread: http://lists.xen.org/archives/html/xen-devel/2013-01/msg00956.html

So the main problem is that the FLASK ruleset he posted is incompatible with 4.2.1. I also talked with Steven Maresca on IRC about this and he said that in 4.2.1 only sysctl hypercalls are support more or less by XSM/FLASK and not domctl hypercalls so I think that these lines are a problem:

# Xenstore requires the global VIRQ for domain destroy operations
allow dom0_t xenstore_t:domain set_virq_handler;
# Current xenstore stubdom uses the hypervisor console, not "xl console"
allow xenstore_t xen_t:xen writeconsole;
# Xenstore queries domaininfo on all domains
allow xenstore_t domain_type:domain getdomaininfo;
# As a shortcut, the following 3 rules are used instead of adding a
domain_comms
# rule between xenstore_t and every domain type that talks to xenstore
create_channel(xenstore_t, domain_type, xenstore_t_channel)
allow event_type xenstore_t: event bind;
allow xenstore_t domain_type:grant { map_read map_write unmap };

Aspecially the first two roles I think won't work, in the case of the other lines I am not sure.

Can I workaround this and find a FLASK ruleset to use xenstored/oxenstored stubdom on 4.2.1?

Best Regards

2013/1/30 Roger Pau Monné <roger.pau@xxxxxxxxxx>

On 30/01/13 12:32, Samuel Thibault wrote:
> Samuel Thibault, le Wed 30 Jan 2013 13:26:08 +0100, a écrit :
>> Samuel Thibault, le Wed 30 Jan 2013 13:20:16 +0100, a écrit :
>>> Roger Pau Monné, le Wed 30 Jan 2013 11:11:00 +0000, a écrit :
>>>> On 30/01/13 11:04, George Dunlap wrote:
>>>>> Yes, PVH is an extension of PV; so only operating systems which can be
>>>>> ported to PV will support PVH.
>>>>
>>>> Isn't it probably easier to port a system with PVHVM support to PVH?
>>>
>>> In general, no. Porting a system to PV involves a lot of tricky things
>>> deep in the OS, while writing a PV driver is much less involving.
>>
>> Let me fix it: porting a system to PVH involves a lot less tricky things
>> deep in the OS than porting it to PV. There are still quite a few tricky
>> things to do, so I don't think PVH is half-way between PV and PVHVM.
>
> Let me fix it again :)
>
> Starting from PV, most of what you need to support PVH is to just drop
> the PV implementation and use the native code, without writing any code.

From what I saw, PVH uses most of the PVHVM code paths, like the PVHVM
vector callback for events (not the PV callback), and grant frames are
also using the PVHVM paths, so I was thinking that the transition from
PVHVM to PVH was going to be easier than the transition from PV to PVH.
But yes, you also need some of the PV tricks, so I'm not sure what will
be more difficult to implement, the PV tricks or the PVHVM infrastructure.

Anyway, it is surely going to be much more easier to port a OS to PVH
from scratch compared to PV.

> So even if it PVH was actually halfway between PVHVM and PV, it surely
> is not halfway between PV and PVHVM :)
>
> Samuel
>

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