[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/5] xen/arm: implement do_hvm_op for ARM



On Tue, 26 Jun 2012, Ian Campbell wrote:
> We need to device how hybrid our hybrid arm guests are going to be.

Right.


> The particular hvm params you are using here (evtchn port etc) typically
> live in start_info for a PV guest. In principal we could define a start
> info for ARM too but that leaves the question of how the guest can find
> it (which loops up back to hvm_params...).

One way would be to introduce a new XENMAPSPACE, like we have done for
XENMAPSPACE_shared_info. Then the guest would use a
XENMEM_add_to_physmap to map it.


> Looking at the other stuff in start_info, it has stuff like modules (aka
> ramdisks) and command lines which ARM guest get via the normal ARM boot
> protocol stuff (i.e. the domain builder does it) and a bunch of stuff
> which seems to only make sense for proper-PV guests.
> 
> So maybe HVM PARAM is the right answer?

Yes, that is one of the reasons why I preferred introducing hvm_op
rather than a new XENMAPSPACE: we don't need anything else from
start_info aside from the parameters already provided through
HVMOP_get_param.
On the other hand hvm_op can be useful for other things, for example one
day we might use the HVM_PARAM_IOREQ_PFN parameter.
Most importantly, from the Linux side of things, acting like a PV on HVM
kernel is a perfect fit, the changes required are down to a minimum.


> sinfo does have flags which contains stuff like SIF_INITIAL_DOMAIN.
> Might we want that?

We don't need it thanks to XENFEAT_dom0, see 
1340381685-22529-3-git-send-email-stefano.stabellini@xxxxxxxxxxxxx

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.