[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IOREQ completions for MMIO writes


  • To: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Jason Andryuk <jason.andryuk@xxxxxxx>
  • Date: Thu, 29 Aug 2024 12:08:35 -0400
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=V/4PyCj6qBL0Fod1a3hAL9UsAlOynP4IHqZ7TGFIxxY=; b=KM663ZBrJsuaKKLDVA8KtprrTueyKYlazxlye0X/J47yiexZyLXBcbbrAuCDP2YTCoqYsS89xClEbB6oq7JfjMO4+qZC6hy0/p4UGfS5Yhxm62f8vW8zBqRfMFDivQw+VoX1zwXT4P980/UwmGL+XZfiL24uicg4tpoFNxDZiiUwgF3UIbtR8IjQRvaXlG1rTwDMOYULcWfjzieQVoFhqmNwHQFKDbUh6SnV92veSwseCVWnd4dJ44ADXRdHnsUwTUVAlsVkqXxDCiez2phVhzRTAByZ1s55nG8e379S0ojT+wj2ipxejVDUC3JoHr+d/9rxhZB24SlhP2uKI8X53A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=hIEuZ2o3H9InWViKC3ZFVXj5Rbolb5ukckhy9QCE+5un/NsnUj/HF+GfGHUROL7a24HfO7OFJugeYagQXyvKYi5mRFvPLJtIHAUL2Rb5ojfJk7NjOXPY0pwFqEC6FQANv5I357U824LYTdn2yWQm4Q1Zl7dog7E5W4kYiGrCG/jbdktKBStZKqAQgh61pykxZ0NoPZkju5/vZ3lGRCskakcqH5w6J3Pe2Q8R+kHrxdcVo5W1vFIQOBv4EsfBqE0FGZdZUH0DTVCOX8Mw24aK0zsG0kSYgtAXORjt4yOuGxDm5OP/Kg6aYzTJOXuLU4+2KP5LFFdt3gI4XEtq67IseA==
  • Delivery-date: Thu, 29 Aug 2024 16:08:53 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Everyone,

I've been looking at ioreq latency and pausing of vCPUs. Specifically for MMIO (IOREQ_TYPE_COPY) writes, they still need completions:

static inline bool ioreq_needs_completion(const ioreq_t *ioreq)
{
    return ioreq->state == STATE_IOREQ_READY &&
           !ioreq->data_is_ptr &&
           (ioreq->type != IOREQ_TYPE_PIO || ioreq->dir != IOREQ_WRITE);
}

state == STATE_IOREQ_READY
data_is_ptr == 0
type == IOREQ_TYPE_COPY
dir == IOREQ_WRITE

To a completion is needed. The vCPU remains paused with _VPF_blocked_in_xen set in paused_flags until the ioreq server notifies of the completion.

At least for the case I'm looking, a single write to a mmio register, it doesn't seem like the vCPU needs to be blocked. The write has been sent and subsequent emulation should not depend on it.

I feel like I am missing something, but I can't think of a specific example where a write needs to be blocking. Maybe it simplifies the implementation, so a subsequent instruction will always have a ioreq slot available?

Any insights are appreciated.

Thanks,
Jason



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.