Domain configuration for DomU

Domain configuration for DomU

[Viktor Kleinik]

[-- Attachment #1.1: Type: text/plain, Size: 996 bytes --]

Hi all,

We are using Linux as Dom0 and Android as DomU on OMAP5 processors
family. Xen version is 4.4-rc2. We have our own devtree configuration file
for
DomU. In our case device tree binary is appended to zImage by using
CONFIG_ARM_APPENDED_DTB option in kernel config for DomU. As I
understood, Xen can determine that there is appended to zImage DTB for
DomU. But it tries to generate its own devtree configuration file via
libxl__arch_domain_configure() function call thru libxl__build_pv()
function in
tools/libxl/libxl_dom.c file. Which is dummy work in that case. In the same
time we have some platform specific configuration which is different from
generic ARM configuration that Xen tries to generate for us. Why Xen tries
to generate its own devtree even if appended to zImage DTB can be
detected? Should we expect some modifications in domain configuration
functions for those cases when DomU requires more platform specific
configuration? Please share your thoughts.

Regards,
Victor

[-- Attachment #1.2: Type: text/html, Size: 1142 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Domain configuration for DomU

[Ian Campbell]

On Mon, 2014-02-24 at 15:55 +0000, Viktor Kleinik wrote:
> We are using Linux as Dom0 and Android as DomU on OMAP5 processors 
> family. Xen version is 4.4-rc2. We have our own devtree configuration file for 
> DomU. In our case device tree binary is appended to zImage by using 
> CONFIG_ARM_APPENDED_DTB option in kernel config for DomU. As I 
> understood, Xen can determine that there is appended to zImage DTB for 
> DomU. But it tries to generate its own devtree configuration file via 
> libxl__arch_domain_configure() function call thru libxl__build_pv() function in 
> tools/libxl/libxl_dom.c file. Which is dummy work in that case.

This is somewhat similar to real hardware too -- the appended DTB would
override anything passed from the bootloader.

> In the same time we have some platform specific configuration which is different from 
> 
> generic ARM configuration that Xen tries to generate for us. Why Xen tries 
> to generate its own devtree even if appended to zImage DTB can be 
> detected?

I think just nobody thought to stop it doing so. I'm not sure how easy
it would be to arrange it anyway -- the thing which knows about the
kernel/appending is a different library to what creates the dtb.

>  Should we expect some modifications in domain configuration 
> functions for those cases when DomU requires more platform specific 
> configuration? Please share your thoughts.

I think as features such as device passthrough get wired up properly in
the toolstack then the generated DTB should reflect this, if that is
what you are asking.

Appending a DTB really ought to become the exception not the rule.

Ian.

Re: Domain configuration for DomU

[Viktor Kleinik]

[-- Attachment #1.1: Type: text/plain, Size: 2244 bytes --]

Ian,

Thank you for your response.

> I'm not sure how easy it would be to arrange it anyway -- the thing
> which knows about the kernel/appending is a different library to
> what creates the dtb.

We will try to implement some alert mechanism between those
two things.

Regards,
Victor


On Mon, Feb 24, 2014 at 4:24 PM, Ian Campbell <Ian.Campbell@citrix.com>wrote:

> On Mon, 2014-02-24 at 15:55 +0000, Viktor Kleinik wrote:
> > We are using Linux as Dom0 and Android as DomU on OMAP5 processors
> > family. Xen version is 4.4-rc2. We have our own devtree configuration
> file for
> > DomU. In our case device tree binary is appended to zImage by using
> > CONFIG_ARM_APPENDED_DTB option in kernel config for DomU. As I
> > understood, Xen can determine that there is appended to zImage DTB for
> > DomU. But it tries to generate its own devtree configuration file via
> > libxl__arch_domain_configure() function call thru libxl__build_pv()
> function in
> > tools/libxl/libxl_dom.c file. Which is dummy work in that case.
>
> This is somewhat similar to real hardware too -- the appended DTB would
> override anything passed from the bootloader.
>
> > In the same time we have some platform specific configuration which is
> different from
> >
> > generic ARM configuration that Xen tries to generate for us. Why Xen
> tries
> > to generate its own devtree even if appended to zImage DTB can be
> > detected?
>
> I think just nobody thought to stop it doing so. I'm not sure how easy
> it would be to arrange it anyway -- the thing which knows about the
> kernel/appending is a different library to what creates the dtb.
>
> >  Should we expect some modifications in domain configuration
> > functions for those cases when DomU requires more platform specific
> > configuration? Please share your thoughts.
>
> I think as features such as device passthrough get wired up properly in
> the toolstack then the generated DTB should reflect this, if that is
> what you are asking.
>
> Appending a DTB really ought to become the exception not the rule.
>
> Ian.
>
>
>
>


-- 

Name | Title
GlobalLogic
P +x.xxx.xxx.xxxx  M +x.xxx.xxx.xxxx  S skype
www.globallogic.com
<http://www.globallogic.com/>
http://www.globallogic.com/email_disclaimer.txt

[-- Attachment #1.2: Type: text/html, Size: 4725 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Domain configuration for DomU

[Ian Campbell]

On Tue, 2014-02-25 at 14:27 +0000, Viktor Kleinik wrote:
> Ian,
> 
> 
> Thank you for your response.
> 
> 
> > I'm not sure how easy it would be to arrange it anyway -- the thing 
> > which knows about the kernel/appending is a different library to 
> > what creates the dtb.
> 
> 
> We will try to implement some alert mechanism between those 
> two things.

Ultimately we should consider exposing whatever it is that causes you to
need to write a custom DTB in the first place via the toolstack in a
first class way. I suppose it is passthrough related?

Ian.