From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 67F5914A0B7 for ; Mon, 29 Jul 2024 13:53:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722261222; cv=none; b=du7EQuVnjG8RyNWfJW5CJe7k4uXBy/Sjt5DEhkn1SscXMT8HMeJc3hzHEypMEFkWS1pXmc0Zx+fLsmFEoXSSJN1ElFAwy8wdsHT0K+lI6OH4V3PD5mkOgnR+INE5yBwLsEq12s3Ss5njX2GKVxvLANBKgNTYX7j0b1zSGHw47wA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722261222; c=relaxed/simple; bh=zevFigggh9gav77vOeUqQEZLN00S3klYyCxmhPrpO0k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=WMBqcsm1ESG07uQuCXzf6N/kxd84hBijmdJNN0a8MikMBOGV/dRh3RqrBldCDCwwHfsgoybjy4ID/Gvn4MuuWm8fV5VLOP58KA06DKXoBEaQVzNnm62vwXYtZKmeJ05vjp4alNiia9S2wdHxxSykt08pTudyGV0WHAXUrDrSFuM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=DhKZrnP3; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="DhKZrnP3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1722261219; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6yEq5CChoNdWngYsHC+lDcujFG99veLH/xTIPSOMsNE=; b=DhKZrnP3TxhUnvl5fLyd12xOmSxvn4skU5fsVqsQEV2PT8pCCWG/snxQSYP+VTDtLyRo90 Gpjvpz1poJL9YSYjHOXtWRY8rEVO6jkk+BtlifOZvFf6yzfjiYvc+00vnClJDauvtOWjqT W+zda9g/c/ZUCPEZV6kUQdqLMPJVYxs= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-61-k9W-6ycDPTeJPqQR543Slg-1; Mon, 29 Jul 2024 09:53:38 -0400 X-MC-Unique: k9W-6ycDPTeJPqQR543Slg-1 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-42820c29a76so2841045e9.2 for ; Mon, 29 Jul 2024 06:53:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722261217; x=1722866017; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6yEq5CChoNdWngYsHC+lDcujFG99veLH/xTIPSOMsNE=; b=uHqnpk20HMtfkCrKGA+SaHtkueebOkPVDHo5aqSLRsJBAI//cefUTZZjsRDmgnofjK vJn8b1/Vec/tmnZMCI+QEYmFBLTFrZpOJ4FSS1Oux9NGUhbrheG2xGoh+xAU6tby6MIa KwFHOtFOE2ASOhymFP3Ak8qDM+OVe3HpnTfIskvDbWP3l9IRsntymDjEpa0dzDitauWi 4Ue/z83iW9a6JXxnRrDISAnFudST+rU49/kwib6YxPFNxamvfxU5y6FhRWhbRKueyGAM O5+Y4vxOSQkVL0lqvTpWL85EyYZSaztS/WFloKiNzqcHi03l4ADtGWmaVIJhvv60DeWH LSzQ== X-Forwarded-Encrypted: i=1; AJvYcCUtTj2O2Ka3typyNKGfI66lNX3eVOZtLwYUZhNedSzCAHkmyggvu0UJpc3SsjToWEuHFBA+3ONY9NtGxGszo/+Ogf23XwLiAEuR+UuzT0+JSF41 X-Gm-Message-State: AOJu0YxAqM3mP96U9pa7izIAMq7em6uQzDv5iOEgmShn3lP/pRZ9OMRP 8mLRysmiK6IEIUsKXmUplp/VtxJ41A3QUh8tJ1X9Hpa9BHzFxeGOa4JMacuPbQtWq5bodJije6g dK5AV8l4ioWq3sa96KOEqRINJfO9bk0JlJZRpdfremrqop+PAOxLzdS/lIYrOxQUVYIDs1g== X-Received: by 2002:a05:600c:444d:b0:426:65bf:5cc2 with SMTP id 5b1f17b1804b1-42811d83c38mr50666535e9.1.1722261216890; Mon, 29 Jul 2024 06:53:36 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEQ34nlwG6HFfNMqNvetJJ+pbG8/TxeOUBuPfISPhjduWTs2MRaELaUuF0Pc7fNro9Ocof+NQ== X-Received: by 2002:a05:600c:444d:b0:426:65bf:5cc2 with SMTP id 5b1f17b1804b1-42811d83c38mr50666185e9.1.1722261216359; Mon, 29 Jul 2024 06:53:36 -0700 (PDT) Received: from fedora (g2.ign.cz. [91.219.240.8]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4280d13570bsm123111095e9.7.2024.07.29.06.53.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jul 2024 06:53:36 -0700 (PDT) From: Vitaly Kuznetsov To: Nicolas Saenz Julienne , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: pbonzini@redhat.com, seanjc@google.com, linux-doc@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-arch@vger.kernel.org, linux-trace-kernel@vger.kernel.org, graf@amazon.de, dwmw2@infradead.org, pdurrant@amazon.com, mlevitsk@redhat.com, jgowans@amazon.com, corbet@lwn.net, decui@microsoft.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, amoorthy@google.com Subject: Re: [PATCH 01/18] KVM: x86: hyper-v: Introduce XMM output support In-Reply-To: References: <20240609154945.55332-1-nsaenz@amazon.com> <20240609154945.55332-2-nsaenz@amazon.com> <87tth0rku3.fsf@redhat.com> Date: Mon, 29 Jul 2024 15:53:34 +0200 Message-ID: <878qxk5mox.fsf@redhat.com> Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Nicolas Saenz Julienne writes: > Hi Vitaly, > Thanks for having a look at this. > > On Mon Jul 8, 2024 at 2:59 PM UTC, Vitaly Kuznetsov wrote: >> Nicolas Saenz Julienne writes: >> >> > Prepare infrastructure to be able to return data through the XMM >> > registers when Hyper-V hypercalls are issues in fast mode. The XMM >> > registers are exposed to user-space through KVM_EXIT_HYPERV_HCALL and >> > restored on successful hypercall completion. >> > >> > Signed-off-by: Nicolas Saenz Julienne >> > >> > --- >> > >> > There was some discussion in the RFC about whether growing 'struct >> > kvm_hyperv_exit' is ABI breakage. IMO it isn't: >> > - There is padding in 'struct kvm_run' that ensures that a bigger >> > 'struct kvm_hyperv_exit' doesn't alter the offsets within that struct. >> > - Adding a new field at the bottom of the 'hcall' field within the >> > 'struct kvm_hyperv_exit' should be fine as well, as it doesn't alter >> > the offsets within that struct either. >> > - Ultimately, previous updates to 'struct kvm_hyperv_exit's hint that >> > its size isn't part of the uABI. It already grew when syndbg was >> > introduced. >> >> Yes but SYNDBG exit comes with KVM_EXIT_HYPERV_SYNDBG. While I don't see >> any immediate issues with the current approach, we may want to introduce >> something like KVM_EXIT_HYPERV_HCALL_XMM: the userspace must be prepared >> to handle this new information anyway and it is better to make >> unprepared userspace fail with 'unknown exit' then to mishandle a >> hypercall by ignoring XMM portion of the data. > > OK, I'll go that way. Just wanted to get a better understanding of why > you felt it was necessary. > (sorry for delayed reply, I was on vacation) I don't think it's an absolute must but it appears as a cleaner approach to me. Imagine there's some userspace which handles KVM_EXIT_HYPERV_HCALL today and we want to add XMM handling there. How would we know if xmm portion of the data is actually filled by KVM or not? With your patch, we can of course check for HV_X64_HYPERCALL_XMM_OUTPUT_AVAILABLE in KVM_GET_SUPPORTED_HV_CPUID but this is not really straightforward, is it? Checking the size is not good either. E.g. think about downstream versions of KVM which may or may not have certain backports. In case we (theoretically) do several additions to 'struct kvm_hyperv_exit', it will quickly become a nightmare. On the contrary, KVM_EXIT_HYPERV_HCALL_XMM (or just KVM_EXIT_HYPERV_HCALL2) approach looks cleaner: once userspace sees it, it knows that 'xmm' portion of the data can be relied upon. -- Vitaly