|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |