Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

On Mon, 15 May 2017, George Dunlap wrote: > [Reducing CC list now that we're off the topic of modules] > > On Fri, May 12, 2017 at 8:04 PM, Volodymyr Babchuk > wrote: > > Stefano, > > > > On 12 May 2017 at 21:43, Stefano Stabellini wrote: > > > >>

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

[Reducing CC list now that we're off the topic of modules] On Fri, May 12, 2017 at 8:04 PM, Volodymyr Babchuk wrote: > Stefano, > > On 12 May 2017 at 21:43, Stefano Stabellini wrote: > >> On the topic of the technical reasons for being out of the

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

Stefano, On 12 May 2017 at 21:43, Stefano Stabellini wrote: > On the topic of the technical reasons for being out of the hypervisor > (EL0 app or stubdom), I'll spend a couple of words on security. > > How large are these components? If they increase the hypervisor code

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

On Fri, 12 May 2017, George Dunlap wrote: > So given your examples, I see no reason not to have several > implementations of different mediators or emulated devices in tree, or > in a XenProject-managed git repo (like mini-os.git). I don't know the > particulars about mediators or the devices you

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

[reordering slightly to make the response easier] On Thu, May 11, 2017 at 7:13 PM, Volodymyr Babchuk wrote: >> Maybe I'm just not familiar with things, but it's hard for me to imagine >> why you'd need proprietary blobs to disable cpus or scale frequency. >> Are these

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

Stefano, >> We, here at EPAM, viewed EL0 apps primarily as a way to extend >> hypervisor. Because when it comes to embedded and automotive, there >> arise some ugly things, that are needed at hypervisor level: >> TEE mediators (OP-TEE is a good TEE, but for example there is TI's >> MSHIELD with

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

George, On 11 May 2017 at 20:14, George Dunlap wrote: >>> We, here at EPAM, viewed EL0 apps primarily as a way to extend >>> hypervisor. Because when it comes to embedded and automotive, there >>> arise some ugly things, that are needed at hypervisor level: >>> TEE

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

On 11/05/17 16:19, Volodymyr Babchuk wrote: > Hi Stefano, > > On 10 May 2017 at 21:24, Stefano Stabellini wrote: > > I just want to point out that the comparision with tasklets is not > > helpful. Tasklets involve the idle vcpu, which we are trying to step away > > from

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

> On 11 May 2017, at 18:20, George Dunlap wrote: > > On Thu, May 11, 2017 at 6:14 PM, Volodymyr Babchuk > wrote: >> Hi George, >> >> On 11 May 2017 at 19:35, George Dunlap wrote: >>> Even better would be to skip the

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

On Thu, May 11, 2017 at 6:14 PM, Volodymyr Babchuk wrote: > Hi George, > > On 11 May 2017 at 19:35, George Dunlap wrote: >> Even better would be to skip the module-loading step entirely, and just >> compile proprietary code directly into your Xen

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

On Thu, May 11, 2017 at 6:14 PM, George Dunlap wrote: > yourself at a risk of meeting a guy like Patrick McHardy[1], a private > individual with copyright on the Linux kernel This should be "copyright on *code in the* Linux Kernel". Obviously he doesn't own a copyright

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

Hi George, On 11 May 2017 at 19:35, George Dunlap wrote: > Even better would be to skip the module-loading step entirely, and just > compile proprietary code directly into your Xen binary. > > Both solutions, unfortunately, are illegal.* Look, I don't saying we want to

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

On 11/05/17 16:35, Julien Grall wrote: > Renaming the subject + adding more people in the conversation as this is > not related to only ARM anymore. > > On 11/05/17 16:19, Volodymyr Babchuk wrote: >> Hi Stefano, >> >> On 10 May 2017 at 21:24, Stefano Stabellini >> wrote:

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

On 11/05/17 16:35, Julien Grall wrote: > On 11/05/17 16:19, Volodymyr Babchuk wrote: >> Hi Stefano, >> >> On 10 May 2017 at 21:24, Stefano Stabellini >> wrote: >>> I just want to point out that the comparision with tasklets is not >>> helpful. Tasklets involve the idle