linux-kernel - Re: [Xen-devel] [RFC PATCH 00/16] xenhost support

Open Source and information security mailing list archives

Message-ID: <29e94cec-66ae-baf0-d189-f9487ce162a7@oracle.com>
Date:   Fri, 7 Jun 2019 22:50:32 -0700
From:   Ankur Arora <ankur.a.arora@...cle.com>
To:     Juergen Gross <jgross@...e.com>,
        Joao Martins <joao.m.martins@...cle.com>
Cc:     sstabellini@...nel.org, konrad.wilk@...cle.com,
        linux-kernel@...r.kernel.org, pbonzini@...hat.com,
        xen-devel@...ts.xenproject.org, boris.ostrovsky@...cle.com
Subject: Re: [Xen-devel] [RFC PATCH 00/16] xenhost support

On 2019-06-07 9:21 a.m., Juergen Gross wrote:
> On 07.06.19 17:22, Joao Martins wrote:
>> On 6/7/19 3:51 PM, Juergen Gross wrote:
>>> On 09.05.19 19:25, Ankur Arora wrote:
>>>> Hi all,
>>>>
>>>> This is an RFC for xenhost support, outlined here by Juergen here:
>>>> https://lkml.org/lkml/2019/4/8/67.
>>>
>>> First: thanks for all the effort you've put into this series!
>>>
>>>> The high level idea is to provide an abstraction of the Xen
>>>> communication interface, as a xenhost_t.
>>>>
>>>> xenhost_t expose ops for communication between the guest and Xen
>>>> (hypercall, cpuid, shared_info/vcpu_info, evtchn, grant-table and on 
>>>> top
>>>> of those, xenbus, ballooning), and these can differ based on the kind
>>>> of underlying Xen: regular, local, and nested.
>>>
>>> I'm not sure we need to abstract away hypercalls and cpuid. I believe in
>>> case of nested Xen all contacts to the L0 hypervisor should be done via
>>> the L1 hypervisor. So we might need to issue some kind of passthrough
>>> hypercall when e.g. granting a page to L0 dom0, but this should be
>>> handled via the grant abstraction (events should be similar).
>>>
>> Just to be clear: By "kind of passthrough hypercall" you mean (e.g. 
>> for every
>> access/modify of grant table frames) you would proxy hypercall to L0 
>> Xen via L1 Xen?
> 
> It might be possible to spare some hypercalls by directly writing to
> grant frames mapped into L1 dom0, but in general you are right.
Wouldn't we still need map/unmap_grant_ref?
AFAICS, both the xenhost_direct and the xenhost_indirect cases should be
very similar (apart from the need to proxy in the indirect case.)

Ankur

> 
> 
> Juergen
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@...ts.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives