Hello Julien,
On 10.05.17 20:40, Julien Grall wrote:
Have you tried to define an interface using C structure?
Not yet.
If not, my suggestion would be to first do that so we can discuss on
other alternative.
Going to take this action soon.
--
*Andrii Anisov*
_
On 05/10/2017 04:30 PM, Andrii Anisov wrote:
Julien,
Hi Andrii,
On 05.05.17 20:51, Julien Grall wrote:
The code is not set in stone. It can be reworked to avoid that.
Yep.
I would like to not introduce changes related to dtb into
libxl_create.c, keep as much as possible in libxl_arm.c .
On 10.05.17 17:22, Ian Jackson wrote:
The IO access emulation just directs the access to somewhere where it
can be emulated. Does that mean you intend for there to be a software
emulation of the vcoproc, as well as hardware passthrough (with
context switching) ?
The concept of an "access emul
Julien,
On 05.05.17 20:51, Julien Grall wrote:
The code is not set in stone. It can be reworked to avoid that.
Yep.
I would like to not introduce changes related to dtb into
libxl_create.c, keep as much as possible in libxl_arm.c . The only
common data structure between libxl__arch_domain_pr
Andrii Anisov writes ("Re: [RFC] scf: SCF device tree and configuration
documentation"):
> On 05.05.17 20:20, Ian Jackson wrote:
> > Why wouldn't the toolstack simply choose appropriate irqs/mmio
> > ranges ? I would expect the virtual irqs/mmio ranges to not
> > necessarily match the physical on
Hello Ian,
On 05.05.17 20:20, Ian Jackson wrote:
Why wouldn't the toolstack simply choose appropriate irqs/mmio
ranges ? I would expect the virtual irqs/mmio ranges to not
necessarily match the physical ones anyway. Is choosing these ranges
complicated ?
This could make sense. Choosing ranges
On 05/05/2017 04:27 PM, Andrii Anisov wrote:
Hello Julien,
On 05.05.17 17:12, Julien Grall wrote:
(CC tools maintainers)
On 04/05/17 17:13, Andrii Anisov wrote:
Julien,
Hi Andrii,
On 04.05.17 15:46, Julien Grall wrote:
I understand these concerns, but not sure should we be scared o
Andrii Anisov writes ("Re: [RFC] scf: SCF device tree and configuration
documentation"):
> On 05.05.17 17:13, Ian Jackson wrote:
> > If these regions of the DT can be marked by this "xen,coproc"
> > property, can't we instead identify them (eg in the libxl domain
> > configuration) by their DT pat
Hello Ian,
On 05.05.17 17:13, Ian Jackson wrote:
I read this proposal.
I agree that putting all the details (interrupts, mmio, etc.) in the
libxl config file is probably undesirable.
AFAICT, there, a particularly coprocessor can be identified as a
portion of the host's DT. Is that right ? T
Hello Julien,
On 05.05.17 17:12, Julien Grall wrote:
(CC tools maintainers)
On 04/05/17 17:13, Andrii Anisov wrote:
Julien,
Hi Andrii,
On 04.05.17 15:46, Julien Grall wrote:
I understand these concerns, but not sure should we be scared of
attack
from a domain privileged enough to run
Julien Grall writes ("Re: [RFC] scf: SCF device tree and configuration
documentation"):
> I have CCed Ian and Wei to comment on the difficult to describe a such
> interface in libxl. They may have insights how to do this properly.
Hi.
> @Ian @Wei: Andrii is suggesting to use Device-Tree for des
(CC tools maintainers)
On 04/05/17 17:13, Andrii Anisov wrote:
Julien,
Hi Andrii,
On 04.05.17 15:46, Julien Grall wrote:
I understand these concerns, but not sure should we be scared of attack
from a domain privileged enough to run domains?
Whilst the domain is privileged enough to ru
On 04/05/17 16:50, Andrii Anisov wrote:
Julien,
Hi Andrii,
What I would like to understand is what are the information that the
hypervisors as to know for sharing co-processor? So far I have:
- MMIOs
- Interrupts
Anything else?
IOMMU bindings.
This knowledge enough to get the physi
Julien,
On 04.05.17 15:46, Julien Grall wrote:
I understand these concerns, but not sure should we be scared of attack
from a domain privileged enough to run domains?
Whilst the domain is privileged enough to run domains, the
configuration can be provided by a user (for instance in cloud
Julien,
What I would like to understand is what are the information that the
hypervisors as to know for sharing co-processor? So far I have:
- MMIOs
- Interrupts
Anything else?
IOMMU bindings.
This knowledge enough to get the physical coprocessor shared.
In order to spawn a virtual
On 04/05/17 13:35, Andrii Anisov wrote:
Hello Julien,
Hi Andrii,
Thank you for your comments.
As you may have seen in the description of the option "device_tree",
it is complex to verify the partial device tree because of the libfdt
design. So without fully auditing libfdt and fixing the
Hello Julien,
Thank you for your comments.
As you may have seen in the description of the option "device_tree",
it is complex to verify the partial device tree because of the libfdt
design. So without fully auditing libfdt and fixing the holes, this
suggestion would be a vector attack to the
On 04/05/17 11:03, Andrii Anisov wrote:
Dear All,
Hi Andrii,
During the topic implementation I faced a nasty issue with a DomU vgic
configuration.
Originally I planned that the partial device tree for DomU is being
passed to the
hypervisor from libxl__arch_domain_create, but it is too late
Dear All,
During the topic implementation I faced a nasty issue with a DomU vgic
configuration.
Originally I planned that the partial device tree for DomU is being
passed to the
hypervisor from libxl__arch_domain_create, but it is too late to set
vgic configuration
at this time. The DomU’s vgi
From: Andrii Anisov
Description of SCF specific device tree properties and SCF configuration
using device tree.
Signed-off-by: Andrii Anisov
---
Dear All,
I would like to present a concept of SCF [1] configuration using device tree.
The idea is that the framework configuration is too complex
20 matches
Mail list logo
