From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C79BC433DF for ; Thu, 6 Aug 2020 12:01:18 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3811422D3E for ; Thu, 6 Aug 2020 12:01:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3811422D3E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1k3cBF-0002TR-SV; Thu, 06 Aug 2020 09:27:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1k3cBF-0002TM-Gi for xen-devel@lists.xenproject.org; Thu, 06 Aug 2020 09:27:21 +0000 X-Inumbo-ID: 3bd3c273-42dd-459a-bc18-41cb4c9eed69 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 3bd3c273-42dd-459a-bc18-41cb4c9eed69; Thu, 06 Aug 2020 09:27:19 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id EE2BFB666; Thu, 6 Aug 2020 09:27:35 +0000 (UTC) Subject: Re: [RFC PATCH V1 07/12] A collection of tweaks to be able to run emulator in driver domain To: Oleksandr References: <1596478888-23030-1-git-send-email-olekstysh@gmail.com> <1596478888-23030-8-git-send-email-olekstysh@gmail.com> <4ffa6434-3ad6-04dc-bfde-f75196930fb4@suse.com> <005f01d66b47$1c58ccc0$550a6640$@xen.org> From: Jan Beulich Message-ID: Date: Thu, 6 Aug 2020 11:27:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: 'Stefano Stabellini' , 'Julien Grall' , 'Wei Liu' , paul@xen.org, 'Andrew Cooper' , 'Ian Jackson' , 'George Dunlap' , 'Oleksandr Tyshchenko' , xen-devel@lists.xenproject.org, 'Daniel De Graaf' Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 06.08.2020 11:22, Oleksandr wrote: > > On 05.08.20 19:40, Paul Durrant wrote: > > Hi Jan, Paul > >>> -----Original Message----- >>> From: Jan Beulich >>> Sent: 05 August 2020 17:20 >>> To: Oleksandr Tyshchenko ; Paul Durrant >>> Cc: xen-devel@lists.xenproject.org; Oleksandr Tyshchenko ; Andrew >>> Cooper ; George Dunlap ; Ian Jackson >>> ; Julien Grall ; Stefano Stabellini >>> ; Wei Liu ; Daniel De Graaf >>> Subject: Re: [RFC PATCH V1 07/12] A collection of tweaks to be able to run emulator in driver domain >>> >>> On 03.08.2020 20:21, Oleksandr Tyshchenko wrote: >>>> From: Oleksandr Tyshchenko >>>> >>>> Trying to run emulator in driver domain I ran into various issues >>>> mostly policy-related. So this patch tries to resolve all them >>>> plobably in a hackish way. I would like to get feedback how >>>> to implement them properly as having an emulator in driver domain >>>> is a completely valid use-case. >>> From going over the comments I can only derive you want to run >>> an emulator in a driver domain, which doesn't really make sense >>> to me. A driver domain has a different purpose after all. If >>> instead you mean it to be run in just some other domain (which >>> also isn't the domain controlling the target), then there may >>> be more infrastructure changes needed. >>> >>> Paul - was/is your standalone ioreq server (demu?) able to run >>> in other than the domain controlling a guest? >>> >> Not something I've done yet, but it was always part of the idea so that we could e.g. pass through a device to a dedicated domain and then run multiple demu instances there to virtualize it for many domUs. (I'm thinking here of a device that is not SR-IOV and hence would need some bespoke emulation code to share it out).That dedicated domain would be termed the 'driver domain' simply because it is running the device driver for the h/w that underpins the emulation. > > I may abuse "driver domain" terminology, but indeed in our use-case we > pass through a set of H/W devices to a dedicated domain which is running > the device drivers for that H/Ws. Our target system comprises a thin > Dom0 (without H/W devices at all), DomD (which owns most of the H/W > devices) and DomU which runs on virtual devices. This patch tries to > make changes at Xen side to be able run standalone ioreq server > (emulator) in that dedicated (driver?) domain. Okay, in which case I'm fine with the term. I simply wasn't aware of the targeted scenario, sorry. Jan