Re: [Xen-devel] [RFC PATCH v2 13/22] xen/arm: its: Add virtual ITS command support

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 5 May 2015, Julien Grall wrote:
> On 05/05/15 11:39, Stefano Stabellini wrote:
> > On Mon, 4 May 2015, Vijay Kilari wrote:
> >> On Thu, Apr 30, 2015 at 7:59 PM, Julien Grall <julien.grall@xxxxxxxxxx> 
> >> wrote:
> >>> Hi,
> >>>
> >>> On 30/04/15 14:47, Stefano Stabellini wrote:
> >>>>>>>
> >>>>>>> If the devid is not within this range, the ITS won't recognize the 
> >>>>>>> value and
> >>>>>>> won't be able to send the interrupt.
> >>>>>>>
> >>>>>>> So this is clearly not the right value.
> >>>>>>
> >>>>>> Sure, in that case the maximum value allowed by GITS_TYPER.Devbits.
> >>>>>> Vijay, what is the value of GITS_TYPER.Devbits on your platform?
> >>>>>
> >>>>> It is 21 bits
> >>>>
> >>>> I would imagine that 21 bits would be plenty to find an unused devid.
> >>>>
> >>>> Alternatively we could use an inexistent function of a real device, such
> >>>> as 00:00.1 (function 1 of the host bridge).
> >>>
> >>> As discussed IRL, this idea sounds good to me.
> >>>
> >>> Although I would be happy with any other way which ensure the devid is 
> >>> free.
> >>
> >> Has prototyped with 00.00.1 as device id. But I see that Dom0 boot is
> >> slow compared to polling mode.
> > 
> > This is very interesting.
> > 
> > 
> >> This could be because Dom0 has to keep
> >> trapping on creader to check if creader is updated or not.
> > 
> > This sounds like a plausible explanation. That's because the guest is
> > polling, right?
> 
> He was inject an INT command for every command sent...
> 
> > I think we should pause the guest vcpu until we receive
> > the interrupt.
> > You can do that by calling vcpu_block.
> 
> Blocking the vcpu is not the right thing to do. The processing of the
> ITS command queue is asynchronous and the guest may decide to execute
> other task while waiting.

Sure, but the hypervisor might have other things to do and other vcpus
to schedule as well. It is a matter of priorities and scheduling the
most appropriate workload. Keep in mind that vcpu_block doesn't
completely pause the guest, it just only blocks the vcpu until the next
guest event occurs.

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