From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: pvops microcode support for AMD FAM >= 15 Date: Mon, 26 Nov 2012 09:58:58 -0500 Message-ID: <50B383B2.9060503@amd.com> References: <1353936077.5830.30.camel@zakaz.uk.xensource.com> <50B3805A02000078000AB1B8@nat28.tlf.novell.com> <1353939218.5830.34.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1353939218.5830.34.camel@zakaz.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: "xen-devel@lists.xen.org" , Jan Beulich , debian-kernel List-Id: xen-devel@lists.xenproject.org On 11/26/2012 09:13 AM, Ian Campbell wrote: > On Mon, 2012-11-26 at 13:44 +0000, Jan Beulich wrote: >>>>> On 26.11.12 at 14:21, Ian Campbell wrote: >>> Debian has decided to take Jeremy's microcode patch [0] as an interim >>> measure for their next release. (TL;DR -- Debian is shipping pvops Linux >>> 3.2 and Xen 4.1 in the next release. See http://bugs.debian.org/693053 >>> and https://lists.debian.org/debian-devel/2012/11/msg00141.html for some >>> more background). >>> >>> However the patch is a bit old and predates the use introduction of >>> separate firmware files for AMD family >= 15h. Looking at the SuSE >>> forward ported classic Xen patches it seems like the following patch is >>> all that is required. But it seems a little too simple to be true and I >>> don't have any such processors to test on. >>> >>> Jan, can you recall if it really is that easy on the kernel side ;-) >> >> While so far I didn't myself run anything on post-Fam10 systems >> either, it really ought to be that easy - the patch format didn't >> change, it's just that they decided to spit the files by family to >> keep them manageable. >> >> The only other thing to check for is that you don't have any >> artificial size restriction left in that code (I think patch files early >> on were limited to 4k in size, and that got lifted during the last >> couple of years). > > I can't find one by inspection, it uses the standard request_firmware > interface and stashes the result in a valloc'd buffer, neither of which > suffer from any 4K related limitations AFAIK. > > I'll try and track something more recent down to test but the worst > downside of applying this patch seems to be that something which doesn't > work still doesn't work. I submitted a fix for fam 16h to Linux right before the Thanksgiving break in US and was planning to look at Xen as well. Give me a day or two to test it. -boris > >> The hypervisor is really going to take care of all other aspects >> here. > > Sweet, thanks. > > Ian. >