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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 27 Jun 2012, Ian Campbell wrote:
> On Tue, 2012-06-26 at 19:29 +0100, Stefano Stabellini wrote:
> > 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.
> 
> That would be in future if/when we support proper "HVM" (or "PVHVM") ARM
> guests i.e. ones which appear to the guest like a particular physical
> platform, rather than our virtual hybrid platform, and therefore have a
> QEMU providing a DM for that hardware?

Yes, that is what HVM_PARAM_IOREQ_PFN would be for.

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