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=-5.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 16B58C43463 for ; Mon, 21 Sep 2020 12:48:00 +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 A380220874 for ; Mon, 21 Sep 2020 12:47:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="d5Ft5r7R" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A380220874 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.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 1kKLE6-0005zb-3w; Mon, 21 Sep 2020 12:47:26 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kKLE4-0005zW-QM for xen-devel@lists.xenproject.org; Mon, 21 Sep 2020 12:47:24 +0000 X-Inumbo-ID: c59e408b-f9d5-437b-83bd-3d6b77765fd8 Received: from mail-lf1-x143.google.com (unknown [2a00:1450:4864:20::143]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id c59e408b-f9d5-437b-83bd-3d6b77765fd8; Mon, 21 Sep 2020 12:47:23 +0000 (UTC) Received: by mail-lf1-x143.google.com with SMTP id w11so13882886lfn.2 for ; Mon, 21 Sep 2020 05:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=8eomZlCDXziZY2pPMtUGf69knKA2Kam3rhgpkCU3KKo=; b=d5Ft5r7RiI1dgDrTrnCLIEJDN+nchH9ZzYrT3R/hRFOCGwguKam2BVEjlHuL2FDh6z 0fUTsNwMA2hfChgE9iszuFQ/qRigLhUeFJKDtg6b+u6MYl74amsMEIzqVxSia9tzaPmG AwDDPf9Ia1+n974YrDZv//tHzirg/qqyYO6BG8Cv8RGfmR6CuozIRFtyyhPxTL1AglWv drPQQVXbtn2djYWUpv5NaSUFxklaf9shstu2obJLmIPrmUYGqhkdQN99m9aBQU53GUmu KTs2mARpRTW4BNFqjB6izzBhWCFfbXEKFGp/fK7jI/BuNguiPMPNsy5grZ90M+EKrgQ3 SmgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=8eomZlCDXziZY2pPMtUGf69knKA2Kam3rhgpkCU3KKo=; b=BSJH2tKWdVkEWZNY9ISzBxDJHFE+b06Kq959GUJlPk73D9OiKp6GtzGyoer4NqKK+Y 9pQd/aEykTGNctqsLD0t/9TxRKYV+wvQBTkUqoN8Gc1vvRDTYGO0mH1yRQ7aHDGUQfzN X8HerzyV1Lq9T+4ZFZeesIzCz5UvbiAUxxklpaW1I1seNAOpfGaRn/WhXWW8+nTzRy05 ZtS9Dg5gVIIABIYLboFFFQDpaBjKB1EIxi2Y5axj5tvsDO8dXgdxOngajulMKlgEDsta 0DAZRdMQlpGOXQ0YfAXxEvODwA+VTXIiKdb1l3zgoMrZaRCRTbaQHRs3j2KONYL+gxX5 Zi0A== X-Gm-Message-State: AOAM533tehgAAX2q5pkKFwlPP3+WKhaBa/DaWlT2iBNN3kJFPaUvWVHe zRCLpE1fDh5JxGndF0Ey5MQ= X-Google-Smtp-Source: ABdhPJxix7lWVRBF3qRybxrav8eEV3FXkbCsLWA9lFDd48XpMzOfv+gj0oD/F9LVsFUvgW6VqQEW3w== X-Received: by 2002:a05:6512:cc:: with SMTP id c12mr14822348lfp.408.1600692442606; Mon, 21 Sep 2020 05:47:22 -0700 (PDT) Received: from [192.168.1.6] ([212.22.223.21]) by smtp.gmail.com with ESMTPSA id m139sm2512149lfa.189.2020.09.21.05.47.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2020 05:47:21 -0700 (PDT) Subject: Re: [PATCH V1 01/16] x86/ioreq: Prepare IOREQ feature for making it common To: Jan Beulich Cc: xen-devel@lists.xenproject.org, Oleksandr Tyshchenko , Paul Durrant , Andrew Cooper , Wei Liu , =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Julien Grall , Stefano Stabellini , Julien Grall References: <1599769330-17656-1-git-send-email-olekstysh@gmail.com> <1599769330-17656-2-git-send-email-olekstysh@gmail.com> <98420567-40a9-7297-d243-4af90f692bf9@suse.com> <123d8e2a-96c2-a97c-a0c0-a5dca4288a2b@gmail.com> <2dea0b83-5178-7768-eaab-ff4a8878eeb0@suse.com> From: Oleksandr Message-ID: Date: Mon, 21 Sep 2020 15:47:21 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <2dea0b83-5178-7768-eaab-ff4a8878eeb0@suse.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US 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: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 21.09.20 15:31, Jan Beulich wrote: Hi > On 21.09.2020 14:22, Oleksandr wrote: >> On 14.09.20 16:52, Jan Beulich wrote: >>> On 10.09.2020 22:21, Oleksandr Tyshchenko wrote: >>>> --- a/xen/arch/x86/hvm/ioreq.c >>>> +++ b/xen/arch/x86/hvm/ioreq.c >>>> @@ -170,6 +170,29 @@ static bool hvm_wait_for_io(struct hvm_ioreq_vcpu *sv, ioreq_t *p) >>>> return true; >>>> } >>>> >>>> +bool arch_handle_hvm_io_completion(enum hvm_io_completion io_completion) >>> Do we need "handle" in here? Without it, I'd also not have to ask about >>> moving hvm further to the front of the name... >> For me without "handle" it will sound a bit confusing because of the >> enum type which >> has a similar name but without "arch" prefix: >> bool arch_hvm_io_completion(enum hvm_io_completion io_completion) > Every function handles something; there's no point including > "handle" in every name. Or else we'd have handle_memset() > instead of just memset(), for example. Got it. Will remove "handle" here. > >> Shall I then move "hvm" to the front of the name here? > As per comments on later patches, I think we want to consider dropping > hvm prefixes or infixes altogether from the functions involved here. >>>> @@ -1215,8 +1233,7 @@ void hvm_destroy_all_ioreq_servers(struct domain *d) >>>> struct hvm_ioreq_server *s; >>>> unsigned int id; >>>> >>>> - if ( !relocate_portio_handler(d, 0xcf8, 0xcf8, 4) ) >>>> - return; >>>> + arch_hvm_ioreq_destroy(d); >>> So the call to relocate_portio_handler() simply goes away. No >>> replacement, no explanation? >> As I understand from the review comment on that for the RFC patch, there >> is no >> a lot of point of keeping this. Indeed, looking at the code I got the >> same opinion. >> I should have added an explanation in the commit description at least. >> Or shall I return the call back? > If there's a reason to drop it (which I can't see, but I also > don't recall seeing the discussion you're mentioning), then doing > so should be a separate patch with suitable reasoning. In the > patch here you definitely should only transform what's already > there. Sounds reasonable. Please see the comment below relocate_portio_handler() here: https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg78512.html However, I might interpret the request incorrectly. -- Regards, Oleksandr Tyshchenko