From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:400c:c09::233; helo=mail-wm0-x233.google.com; envelope-from=julien.grall@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CDF8E203525F2 for ; Thu, 26 Oct 2017 11:28:00 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id p75so9665631wmg.3 for ; Thu, 26 Oct 2017 11:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=77qCT9By1G/lI4mmJIwkuYrRlCKd0YFc3natlmIfa0w=; b=BOhCpUSQWMg28M5dqc1Jd4IIt4JdPACzZAvn3nIXwq1E2QX9wlKvP4lQqQkhWnsdu/ X/ma2vibS9rfLM7gEx6wofGyLm4Z8P87dwKIpmrN+W5Km9wSovB2fCIz1jtatsovC1sY /fbxgu1mfMup/pFPGlgc1rFVT49bwEk1Iwym0= 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-language :content-transfer-encoding; bh=77qCT9By1G/lI4mmJIwkuYrRlCKd0YFc3natlmIfa0w=; b=fFZl+1/Sh5cmmr4/VhGk2LBSbyJuSaPLjzMJbjt9RjMcWrm59nqlche6gNAFmWkRFW xXGGE0PgrCWt6Auw3mbEF7nQfZhm1/GRLknPnqlE7yZVBMzjBCzHRPR2aok9n8VxjDa6 vN4V2jqQLJxnHLesXosM3+rA7jc/qgSplAwSGLfyt3B78biNLsiuFw5raqhPBfOyElfr uhjF2WvrI/QgK4T7fh/otsVyuaiw9Kg+9FlbvMv1E2WjiJ6xBrwrGj118pkttalm75zW /CNXjoHpNgSiO4ImWEtqQLTjl0alBvd3j8mL/tkxKjvWLsWbdqMB99fChfAXGqPqSfB6 /WwA== X-Gm-Message-State: AMCzsaWFhyrKamg6FU3SePboOeOMoxicNe5KtyZ/GZoizWpFMbsuGXCW V7exmQV64qko9F8Ut3fwvBUJ5A== X-Google-Smtp-Source: ABhQp+S2Z8c0YEzmoqazG4aMAqxDf4dAeVgBvX5VHcojXhwuxCQxrfX5oCKYDVnJ6IGdJyeHp8EOnQ== X-Received: by 10.28.74.86 with SMTP id x83mr2537068wma.146.1509042705514; Thu, 26 Oct 2017 11:31:45 -0700 (PDT) Received: from ?IPv6:::1? ([2001:41d0:1:6c23::1]) by smtp.gmail.com with ESMTPSA id s18sm4413469wrg.87.2017.10.26.11.31.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 11:31:44 -0700 (PDT) To: Laszlo Ersek , edk2-devel-01 , star.zeng@intel.com, heyi.guo@linaro.org, ruiyu.ni@intel.com Cc: Anthony PERARD , Leif Lindholm , Ard Biesheuvel References: <7516a301-dfbb-5bd4-5e1e-ccd18c26db30@linaro.org> <74e0ac36-195f-9275-922e-e499a513569f@redhat.com> <32b3c432-7f17-c387-5334-a6826d6fa769@redhat.com> From: Julien Grall Message-ID: Date: Thu, 26 Oct 2017 19:31:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <32b3c432-7f17-c387-5334-a6826d6fa769@redhat.com> Subject: Re: Xen Console input very slow in recent UEFI X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 18:28:01 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Laszlo, Thank you for your help. On 26/10/17 16:20, Laszlo Ersek wrote: > On 10/26/17 17:13, Laszlo Ersek wrote: >> Hello Julien, >> >> On 10/26/17 13:05, Julien Grall wrote: >>> Hi all, >>> >>> I was doing more testing of UEFI in Xen guests and noticed some slow >>> down when using the shell. The characters are only echoed after a second >>> or two that is a bit annoying. >>> >>> The change that introduced this issue is 4cf3f37c87 "MdeModulePkg >>> SerialDxe: Process timeout consistently in SerialRead". >>> >>> The Serial Driver for Xen PV console is very simple (see >>> OvmfPkg/Library/XenConsoleSerialPortLib). So I am not sure where the >>> root cause is. >>> >>> Would anyone have any tips on it? >> >> The exact same issue has been encountered earlier under QEMU, please >> refer to the following sub-thread (please read it to end): >> >> http://mid.mail-archive.com/b748580c-cb51-32c9-acf9-780841ef15da@redhat.com >> >> The fix was commit 5f0f5e90ae8c ("ArmVirtPkg/FdtPL011SerialPortLib: call >> PL011UartLib in all SerialPortLib APIs", 2017-08-16). >> >> I think if you can implement the same for XenConsoleSerialPortLib, that >> should return to working state as well. > > Hmmm, wait, at a closer look, it looks like > > OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.c > > already implements that suggestion? (I.e., it sets > EFI_SERIAL_INPUT_BUFFER_EMPTY in *Control as necessary?) > > Are we sure the SerialPortPoll() function works correctly? I don't see > any MemoryFence() calls in SerialPortPoll(), around checking the fields > in (*mXenConsoleInterface). Could that be the problem? I am not entirely sure. But I added a couple of MemoryFence() in SerialPort just in case to clear that from potential cause: XENCONS_RING_IDX Consumer, Producer; if (!mXenConsoleInterface) { return FALSE; } MemoryFence (); Consumer = mXenConsoleInterface->in_cons; Producer = mXenConsoleInterface->in_prod; MemoryFence (); return Consumer != Producer; I also added some debug printk (using a different interface) to confirm the value of Consumer and Producer are valid. I can see the Producer increasing every time a key is pressed and then soon followed by SerialPortRead incrementing Consumer. I did more debugging and find out the following is happening in TerminalConInTimerHandler (MdeModulePkg/Universal/Console/TerminalDxe) when a character is received: 1) GetControl will return EFI_SERIAL_INPUT_BUFFER_EMPTY unset => Entering in the loop to fetch character from the serial 2) GetOneKeyFromSerial() => Return directly with the character read 3) Looping as the fifo is not full and no error 4) GetOneKeyFromSerial() -> SerialRead() => No more character so SerialPortPoll() will return FALSE and loop until timeout => Return EFI_TIMEOUT 5) Exiting the loop from TerminalConInTimerHandler 6) Characters are printed So the step 4) will introduce the timeout seen and delay the echoing of the characters received. I could see a couple of solutions to fix it: 1) Remove the timeout from SerialPortRead and rely on either a) caller to handle timeout b) each UART driver 2) TerminalConInTimerHandler to check at every iteration whether the buffer is empty. Any other ideas? Cheers, -- Julien Grall