linux-kernel - Re: [RFC PATCH 09/16] xen/evtchn: support evtchn in xenhost

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 16 Jun 2019 23:09:22 -0700
From:   Ankur Arora <ankur.a.arora@...cle.com>
To:     Juergen Gross <jgross@...e.com>, linux-kernel@...r.kernel.org,
        xen-devel@...ts.xenproject.org
Cc:     pbonzini@...hat.com, boris.ostrovsky@...cle.com,
        konrad.wilk@...cle.com, sstabellini@...nel.org,
        joao.m.martins@...cle.com
Subject: Re: [RFC PATCH 09/16] xen/evtchn: support evtchn in xenhost_t

On 2019-06-14 5:04 a.m., Juergen Gross wrote:
> On 09.05.19 19:25, Ankur Arora wrote:
>> Largely mechanical patch that adds a new param, xenhost_t * to the
>> evtchn interfaces. The evtchn port instead of being domain unique, is
>> now scoped to xenhost_t.
>>
>> As part of upcall handling we now look at all the xenhosts and, for
>> evtchn_2l, the xenhost's shared_info and vcpu_info. Other than this
>> event handling is largley unchanged.
>>
>> Note that the IPI, timer, VIRQ, FUNCTION, PMU etc vectors remain
>> attached to xh_default. Only interdomain evtchns are allowable as
>> xh_remote.
> 
> I'd do only the interface changes for now (including evtchn FIFO).
Looking at this patch again, it seems to me that it would be best to
limit the interface change (to take the xenhost_t * parameter) only to
bind_interdomain_*. That also happily limits the change to the drivers/
subtree.

> 
> The main difference will be how to call the hypervisor for sending an
> event (either direct or via a passthrough-hypercall).
Yeah, though, this would depend on how the evtchns are mapped (if it's
the L1-Xen which is responsible for mapping the evtchn on behalf of the 
L0-Xen, then notify_remote_via_evtchn() could just stay the same.)
Still, I'll add a send interface (perhaps just an inline function) to
the xenhost interface for this.

Ankur

> 
> 
> Juergen