[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC 21/24] xen/arm: vexpress: Blacklist a list of board specific devices



On Thu, 2013-08-22 at 15:51 +0100, Julien Grall wrote:
> On 08/22/2013 03:36 PM, Ian Campbell wrote:
> > On Thu, 2013-08-22 at 15:24 +0100, Julien Grall wrote:
> >> On 08/22/2013 03:00 PM, Ian Campbell wrote:
> >>> On Fri, 2013-08-16 at 22:05 +0100, Julien Grall wrote:
> >>>> On Versatile there is a bunch of devices that must not pass-through to 
> >>>> any
> >>>
> >>> "there are a bunch of devices which must not be passed-through"
> >>>
> >>>> guest (power management and cache coherency devices).
> >>>>
> >>>> This commit also blacklist the HDLCD device because then is unable to 
> >>>> correctly
> >>>                                                           ^Linux?
> >>>
> >>>> map the framebuffer. Therefore, when Linux will try to access to the 
> >>>> framebuffer,
> >>>> Xen will receive a non-handled data access.
> >>>
> >>> Can/should this be conditional on whether Xen has console=hdlcd or not?
> >>> Or does Xen use the device unconditionally if it exists? TBH I think it
> >>> would be normal to prefer that Linux gets this device...
> >>>
> >>> (I'm unclear how this relates to memreserve as mention in the code
> >>> comment)
> >>
> >> This issue is only when the HDLCD is used by Linux (not Xen). To specify
> >> where the framebuffer lives in the memory, there is a property
> >> "framebuffer" which contains address/size.
> >> This regions must be reserved to avoid Linux/u-boot play with it. So the
> >> DTS has a memreserve range with the same value. I don't really
> >> understand all memreserve things but Xen must cope with it.
> > 
> > Yes, Xen needs to learn memreserve, it's used on midway too for example.
> 
> As I understand memreserve can only contains RAM region. Right?

ePAPR seems to suggest it is only for RAM, yes.

> > It seems like it would be hard to link an individual memsreserve to a
> > particular device, at least not without device specific logic (e.g
> > looking at the "framebuffer" property in this case).
> > 
> > Sounds like we might need list of compatible -> dom0_init_hook
> > functions, with the appropriate hook called for each device which we
> > pass through.
> 
> It could be a solution. In this case, we just need to update the
> framebuffer property and the memreserve.

I think in this case we probably want to create a 1:1 mapping of the
video ram? In case e.g. the firmware has setup attributes, or the LCD
cannot use a different address etc...

> 
> > 
> > Ian.
> > 
> >>
> >> This solution is not upstream (only in the Linaro tree). I don't know if
> >> this driver works with the vanilla kernel.
> >>
> >>>
> >>>>
> >>>> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
> >>>> ---
> >>>>  xen/arch/arm/platforms/vexpress.c |   17 +++++++++++++++++
> >>>>  1 file changed, 17 insertions(+)
> >>>>
> >>>> diff --git a/xen/arch/arm/platforms/vexpress.c 
> >>>> b/xen/arch/arm/platforms/vexpress.c
> >>>> index 8fc30c4..ece7bd9 100644
> >>>> --- a/xen/arch/arm/platforms/vexpress.c
> >>>> +++ b/xen/arch/arm/platforms/vexpress.c
> >>>> @@ -125,9 +125,26 @@ static const char const *vexpress_dt_compat[] 
> >>>> __initdata =
> >>>>      NULL
> >>>>  };
> >>>>  
> >>>> +static const struct dt_device_match vexpress_blacklist_dev[] 
> >>>> __initconst =
> >>>> +{
> >>>> +    /* Cache Coherent Interconnect */
> >>>> +    DT_MATCH_COMPATIBLE("arm,cci-400"),
> >>>> +    DT_MATCH_COMPATIBLE("arm,cci-400-pmu"),
> >>>> +    /* Video device
> >>>> +     * TODO: remove it once memreserve is handled properly by Xen
> >>>> +     */
> >>>> +    DT_MATCH_COMPATIBLE("arm,hdlcd"),
> >>>> +    /* Hardware power management */
> >>>> +    DT_MATCH_COMPATIBLE("arm,vexpress-reset"),
> >>>> +    DT_MATCH_COMPATIBLE("arm,vexpress-reboot"),
> >>>> +    DT_MATCH_COMPATIBLE("arm,vexpress-shutdown"),
> >>>> +    { /* sentinel */ },
> >>>> +};
> >>>> +
> >>>>  PLATFORM_START(vexpress, "VERSATILE EXPRESS")
> >>>>      .compatible = vexpress_dt_compat,
> >>>>      .reset = vexpress_reset,
> >>>> +    .blacklist_dev = vexpress_blacklist_dev,
> >>>>  PLATFORM_END
> >>>>  
> >>>>  /*
> >>>
> >>>
> >>
> >>
> > 
> > 
> 
> 



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.