From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [PATCH 1/5] xen/arm: implement do_hvm_op for ARM Date: Wed, 27 Jun 2012 12:04:00 +0100 Message-ID: References: <1340381373-22177-1-git-send-email-stefano.stabellini@eu.citrix.com> <1340720842.3832.137.camel@zakaz.uk.xensource.com> <1340787770.29172.19.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1340787770.29172.19.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "xen-devel@lists.xensource.com" , "Tim (Xen.org)" , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org 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.