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

[Bhupinder Thakur <bhupinder.thakur@xxxxxxxxxx>]

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).

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.

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