From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 2/4] tools/libxc: Use an explicit check for PV MSRs in xc_domain_save() Date: Fri, 6 Jun 2014 10:44:53 +0100 Message-ID: <53918D95.4080504@citrix.com> References: <1401902794-15542-1-git-send-email-andrew.cooper3@citrix.com> <1401902794-15542-3-git-send-email-andrew.cooper3@citrix.com> <1401983546.15729.150.camel@hastur.hellion.org.uk> <5390936C.5010308@citrix.com> <1402046150.31120.0.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1402046150.31120.0.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Ian Jackson , Jan Beulich , Xen-devel List-Id: xen-devel@lists.xenproject.org On 06/06/14 10:15, Ian Campbell wrote: > On Thu, 2014-06-05 at 16:57 +0100, Andrew Cooper wrote: >> To avoid a race condition with the vcpu touching a new MSR between the >> two hypercalls, Xen must return the maximum possible msr_count with the >> request for size, so the toolstack can guarantee to allocate a large >> enough buffer. > If the msr_count returned a build time constant can't it just be part of > the interface then? Either as #define or an explicitly sized array type > somewhere. > > Ian. > The maximum possible msr_count depends on architecture, features available and, plausibly, domain cpuid policy. At the moment it is trivial, Intel = 0 and AMD = {0, 4}, but this will get more complicated as we add support for more MSRs. The information does have to be made available on a per-domain basis. ~Andrew