Re: [Xen-devel] Xen ARM - Exposing a PL011 to the guest

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

Hello Bhupinder,

it is good to hear that you are making progress.


On Fri, 6 Jan 2017, Bhupinder Thakur wrote:
> Hi,
> 
> I am trying to allocate a new SPI VIRQ for sending pl011 interrupt to
> the guest OS. Currently Xen does not allow to allocate a SPI VIRQ for
> a guest domain. I tried allocating a new SPI VIRQ by calling
> vgic_allocate_spi() but it failed as the SPI VIRQ range for the guests
> is limited to 0 (vgic_num_irqs() return 32 and therefore in effect
> says that no SPI VIRQ can be allocated because below 32 are for
> PPI/SGI VIRQs).

Yes, you should use vgic_allocate_virq. For that to work, you need to
make sure that nr_spis for the domain is > 0. Given that nr_spis is
passed from libxl by calling xc_domain_create, I would set nr_spis to 1
in libxl__arch_domain_prepare_config.


> I tried modifying the guest domU configuration to specify the SPI IRQs
> to be allowed for the guest but that operation fails as it is not
> allowed for the unprivileged guests. Is there a way to allow a SPI
> VIRQ to be allocated to a guest OS. I could not find any instance in
> the Xen where it is allocating a SPI VIRQ.

If you have already tried what I suggested, could you please post the
error you are getting?


> I was able to register a new PPI VIRQ for pl011 interrupt and could
> inject that interrupt into the guest and handle the interrupt in the
> guest.
> 
> Regards,
> Bhupinder
> 
> On 4 January 2017 at 01:38, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> > On Thu, 29 Dec 2016, Bhupinder Thakur wrote:
> >> On 28 December 2016 at 23:19, Julien Grall <julien.grall@xxxxxxx> wrote:
> >> > On 21/12/16 22:12, Stefano Stabellini wrote:
> >> >>
> >> >> On Wed, 21 Dec 2016, Julien Grall wrote:
> >> >>>
> >> >>> On 20/12/2016 20:53, Stefano Stabellini wrote:
> >> >>>>
> >> >>>> On Tue, 20 Dec 2016, Julien Grall wrote:
> >> >>>>>
> >> >>>>> On 19/12/2016 21:24, Stefano Stabellini wrote:
> >> >>>>>>
> >> >>>>>> On Mon, 19 Dec 2016, Christoffer Dall wrote:
> >> >>>>>>>
> >> >>>>>>> On Fri, Dec 16, 2016 at 05:03:13PM +0000, Julien Grall wrote:
> >> >>>>>>
> >> >>>>>> If we use hvm_params for this, we need two new hvm_params and Xen
> >> >>>>>> needs
> >> >>>>>> to unmap the pfn from the guest immediately, because we don't want 
> >> >>>>>> the
> >> >>>>>> guest to have access to it.
> >> >>>>>
> >> >>>>>
> >> >>>>> If you unmap the pfn, the PV backend will not be able to request the
> >> >>>>> page
> >> >>>>> because there will be no translation available.
> >> >>>>>
> >> >>>>> So what you want to do is preventing the guest to at least write into
> >> >>>>> region
> >> >>>>> (not sure if it is worth to restrict read)
> >> >>>>
> >> >>>>
> >> >>>> That's a good idea.
> >> >>>>
> >> >>>>
> >> >>>>> and unmap the page via the hypercall XENMEM_decrease_reservation.
> >> >>>>
> >> >>>>
> >> >>>> That would be issued by the guest itself, right? To save address 
> >> >>>> space?
> >> >>>
> >> >>>
> >> >>> Correct. The main use case today is ballooning, but guest could call it
> >> >>> on any
> >> >>> other RAM baked page.
> >> >>>
> >> >>> I was thinking about more about the protection needed. Technically the
> >> >>> data in
> >> >>> the ring are not trusted. So if the guest is messing up with it, it 
> >> >>> would
> >> >>> not
> >> >>> be a big issue. Or did I miss anything here?
> >> >>
> >> >>
> >> >> I understand that a guest would be smart to call
> >> >> XENMEM_decrease_reservation on the PV console page for pl011, but it
> >> >> cannot be a security measure, because, in fact, it needs to be called by
> >> >> the guest.  Of course, a malicious guest can simply not call
> >> >> XENMEM_decrease_reservation for it.
> >> >
> >> >
> >> > Sorry I was not clear. I was not suggested the guest to call
> >> > XENMEM_decrease_reservation on ring for security but a malicious guest
> >> > issuing the hypercall on the ring protected and replacing by another 
> >> > page.
> >> >
> >> > This is the exact same problem as the one I mentioned on the ITS thread. 
> >> > The
> >> > page live in guest memory but contains data that will only be touched by
> >> > Xen.
> >> >
> >> > If you remove those page from stage-2, the translation IPA -> MFN will be
> >> > lost unless you store somewhere else. You would have to do it per-page as
> >> > the buffer will use contiguous IPA but potentially noncontiguous MFN.
> >> >
> >> > In the case of ITS the memory is provisioned by the guest. So there are 
> >> > not
> >> > much to do there except adding protection in stage-2 such as write
> >> > protection and preventing the guest to unmap it. However for the pl011 
> >> > ring,
> >> > as Andrew pointed on IRC, what we need to do is accounting this page to 
> >> > the
> >> > domain memory. No mapping is necessary in stage-2.
> >>
> >> Please clarify what is meant by that no stage-2 mapping is required.
> >> Does it mean that no stage-2 mapping is required for the guest as it
> >> never needs to access this page?
> >
> > That's right.
> >
> >
> >> However, the Xen HYP will need the stage-2 mapping to find out the
> >> pl011 PFN --> physical MFN mapping so that it can map the page to its
> >> own address space. Currently, I am using prepare_ring_for_helper () to
> >> map the pl011 PFN (passed via hvm call) ---> phyiscal MFN ---> Xen HYP
> >> VA.
> >
> > I am not sure what Julien had in mind exactly. I like the idea of not
> > mapping the page at stage-2, but it is true that many interfaces expect
> > pfns. If Xen is the one to allocate the pl011 PV console page, then Xen
> > knows the mfn and could use it to map the page, instead of the pfn.
> > However, the PV console backend also needs to map the same page, and it
> > currently does that by calling xc_map_foreign_range, which I believe
> > also expect a pfn.
> >
> > So maybe it is easier to use write-protection in stage-2 (as for ITS),
> > unless Julien has a better idea?
> 

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