[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |