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=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 AED80C11F69 for ; Fri, 9 Jul 2021 13:43:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9CCC66135C for ; Fri, 9 Jul 2021 13:43:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232064AbhGINpo (ORCPT ); Fri, 9 Jul 2021 09:45:44 -0400 Received: from mail-wr1-f50.google.com ([209.85.221.50]:36549 "EHLO mail-wr1-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231993AbhGINpk (ORCPT ); Fri, 9 Jul 2021 09:45:40 -0400 Received: by mail-wr1-f50.google.com with SMTP id v5so12235843wrt.3; Fri, 09 Jul 2021 06:42:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Q7mB1luMo6HbqDXiBnl1Lwdd0jsa0W6EKAtYOrdTCZQ=; b=by///3buMRDDAm1A8U7VKz6X350wmpKMSldK1WiuThHZiEyb4BcCH2hl8tJE7M6Anr EKPn5lEltKEdZPKF3zL7TyJv/aZ9WygwGWaxhSxtxSsxeSbxxvnhdHHVrW1wuSkXDBiM HoCW5XwiZJxYUPyEX4AaiWbuJhEAY4wVIqFcKrJuOhlGgp+Q2qC8f2Netad7vX2upUrB /Z0STFweCxfh/pKiHenf0+SIKLZRgwJjiVnPQEsPDf/iIFKg66zD5MVVUbLIa94KeMqz IIiZIZREmEIhlFHj7sSam4ARMQkagHVkf3O82B6ODjccqidrfufNuXL2yOgvRkGdLtH7 eZNw== X-Gm-Message-State: AOAM5306huwZM+ntLyAlw11CwvKcVqyAWRNJs3f7k4FqSwRFcNK86cKH nyjeDWYxabQoiHgf1oOG/xs= X-Google-Smtp-Source: ABdhPJy1Vhv89E6JlCPqe86nNsogAgxU+t9rVvrr2JLaDugrBsREJ7+fYhw4wwqlJCIcXWLMD2M1ow== X-Received: by 2002:adf:fd4d:: with SMTP id h13mr36177102wrs.5.1625838175836; Fri, 09 Jul 2021 06:42:55 -0700 (PDT) Received: from liuwe-devbox-debian-v2 ([51.145.34.42]) by smtp.gmail.com with ESMTPSA id s9sm5305291wrn.87.2021.07.09.06.42.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Jul 2021 06:42:55 -0700 (PDT) Date: Fri, 9 Jul 2021 13:42:53 +0000 From: Wei Liu To: Robin Murphy Cc: Wei Liu , Linux on Hyper-V List , pasha.tatashin@soleen.com, Will Deacon , kumarpraveen@linux.microsoft.com, David Woodhouse , Linux Kernel List , Michael Kelley , "open list:INTEL IOMMU VT-d" , Nuno Das Neves , Sunil Muthuswamy , virtualization@lists.linux-foundation.org, Vineeth Pillai , Jean-Philippe Brucker Subject: Re: [RFC v1 3/8] intel/vt-d: make DMAR table parsing code more flexible Message-ID: <20210709134253.274m4dpqukxn43q7@liuwe-devbox-debian-v2> References: <20210709114339.3467637-1-wei.liu@kernel.org> <20210709114339.3467637-4-wei.liu@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 09, 2021 at 01:56:46PM +0100, Robin Murphy wrote: > On 2021-07-09 12:43, Wei Liu wrote: > > Microsoft Hypervisor provides a set of hypercalls to manage device > > domains. The root kernel should parse the DMAR so that it can program > > the IOMMU (with hypercalls) correctly. > > > > The DMAR code was designed to work with Intel IOMMU only. Add two more > > parameters to make it useful to Microsoft Hypervisor. Microsoft > > Hypervisor does not need the DMAR parsing code to allocate an Intel > > IOMMU structure; it also wishes to always reparse the DMAR table even > > after it has been parsed before. > > We've recently defined the VIOT table for describing paravirtualised IOMMUs > - would it make more sense to extend that to support the Microsoft > implementation than to abuse a hardware-specific table? Am I right in I searched for VIOT and believed I found the correct link https://lwn.net/Articles/859291/. My understanding is based on the reading of that series. VIOT is useful. I think it solves the problem for guests. It does not solve the problem we have though. The DMAR tables are not conjured up by some backend software running on the host side. They are the real tables provided by the firmware. The kernel here is part of the host setup, dealing with physical hardware. No matter how much I wish all vendors unified their tables, I don't see how that's going to happen for readily available servers. :-( > assuming said hypervisor isn't intended to only ever run on Intel hardware? Yes, that's correct. We also plan to add support AMD and ARM64. Wei.