From mboxrd@z Thu Jan 1 00:00:00 1970 From: Laszlo Ersek Subject: Re: [PATCH v4 3/3] i386: publish advised value of MSR_IA32_FEATURE_CONTROL via fw_cfg Date: Fri, 17 Jun 2016 23:30:40 +0200 Message-ID: References: <20160616060621.30422-1-haozhong.zhang@intel.com> <20160616060621.30422-4-haozhong.zhang@intel.com> <20160616111951.yvmr6tznzw6tyxlx@hz-desktop> <603c703c-5142-4721-e5a3-2d147c32ccd1@redhat.com> <20160617202118.GA8131@linux.intel.com> <126a858e-f88a-3023-c7fe-a531c780121c@redhat.com> <20160617205555.GA8245@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Haozhong Zhang , Paolo Bonzini , qemu-devel@nongnu.org, Richard Henderson , Eduardo Habkost , "Michael S . Tsirkin" , Marcelo Tosatti , kvm@vger.kernel.org, Boris Petkov , Tony Luck , Andi Kleen , rkrcmar@redhat.com To: "Raj, Ashok" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:54728 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752644AbcFQVap (ORCPT ); Fri, 17 Jun 2016 17:30:45 -0400 In-Reply-To: <20160617205555.GA8245@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/17/16 22:55, Raj, Ashok wrote: > On Fri, Jun 17, 2016 at 10:48:17PM +0200, Laszlo Ersek wrote: >> On 06/17/16 22:21, Raj, Ashok wrote: >>> On Fri, Jun 17, 2016 at 07:31:08PM +0200, Laszlo Ersek wrote: >>>>>> >>>>>> On 16/06/2016 08:06, Haozhong Zhang wrote: >>>>>>> It's a prerequisite that certain bits of MSR_IA32_FEATURE_CONTROL should >>>>>>> be set before some features (e.g. VMX and LMCE) can be used, which is >>>>>>> usually done by the firmware. This patch adds a fw_cfg file >>>>>>> "etc/msr_feature_control" which contains the advised value of >>>>>>> MSR_IA32_FEATURE_CONTROL and can be used by guest firmware (e.g. SeaBIOS). >>>>>>> >>> >>> I'm sorry i'm joining this discussion a bit late returning from vacation. >>> In a real platform supporting LMCE, BIOS is responsible for setting the bits >>> for IA32_FEATURE_CONTROL correctly. There are good reasons why we want the >>> BIOS to play this role. >>> >>> in a virtualized environment, do we really have to push the same requirement >>> or would it suffice to just emulate it as we did in the early patches. >>> >>> Not sure what exact problem is created by just simply supporting it within >>> kvm/qemu and not needing the bios for the guest to also adapt these changes. >> >> At the moment, my understanding of this feature is superficial, but the >> mechanisms involved in it don't seem complex. I don't expect >> difficulties implementing it, I just need the details that I asked for >> spelled out for me. >> >> As to why we should be doing this in the guest firmware(s) -- "because >> that's what happens on physical machines too" :) Following the phys >> world to the letter in virt is not always a goal, but it's never wrong. > > But the guest bios does nothing like the BIOS in the real platform. That's overstated. The guest firmwares do a lot of things they also do on physical hardware. PCI enumeration / resource assignment, for example. > for e.g. a real bios would have SMM handlers to work for implementing firmware > first mechanisms before notifying the OS. None of these exist in the > virtalized world. Both SeaBIOS and OVMF utilize SMM, for various purposes. OVMF's goals with SMM are briefly documented here: . For SMM support, all of KVM, QEMU, and OVMF needed (many) patches. Anyway, I'm neutral on this. If the consensus is that the MSR at hand is none of the guest firmware's business, I won't object -- hey, it's only less work for me. OTOH, if the consensus is that SeaBIOS should be aware of the MSR, then it follows that so should OVMF. Thanks Laszlo From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bE1Ll-00075N-R1 for qemu-devel@nongnu.org; Fri, 17 Jun 2016 17:30:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bE1Lh-0002qO-Ld for qemu-devel@nongnu.org; Fri, 17 Jun 2016 17:30:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57908) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bE1Lh-0002qK-Cs for qemu-devel@nongnu.org; Fri, 17 Jun 2016 17:30:45 -0400 References: <20160616060621.30422-1-haozhong.zhang@intel.com> <20160616060621.30422-4-haozhong.zhang@intel.com> <20160616111951.yvmr6tznzw6tyxlx@hz-desktop> <603c703c-5142-4721-e5a3-2d147c32ccd1@redhat.com> <20160617202118.GA8131@linux.intel.com> <126a858e-f88a-3023-c7fe-a531c780121c@redhat.com> <20160617205555.GA8245@linux.intel.com> From: Laszlo Ersek Message-ID: Date: Fri, 17 Jun 2016 23:30:40 +0200 MIME-Version: 1.0 In-Reply-To: <20160617205555.GA8245@linux.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 3/3] i386: publish advised value of MSR_IA32_FEATURE_CONTROL via fw_cfg List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Raj, Ashok" Cc: Haozhong Zhang , Paolo Bonzini , qemu-devel@nongnu.org, Richard Henderson , Eduardo Habkost , "Michael S . Tsirkin" , Marcelo Tosatti , kvm@vger.kernel.org, Boris Petkov , Tony Luck , Andi Kleen , rkrcmar@redhat.com On 06/17/16 22:55, Raj, Ashok wrote: > On Fri, Jun 17, 2016 at 10:48:17PM +0200, Laszlo Ersek wrote: >> On 06/17/16 22:21, Raj, Ashok wrote: >>> On Fri, Jun 17, 2016 at 07:31:08PM +0200, Laszlo Ersek wrote: >>>>>> >>>>>> On 16/06/2016 08:06, Haozhong Zhang wrote: >>>>>>> It's a prerequisite that certain bits of MSR_IA32_FEATURE_CONTROL should >>>>>>> be set before some features (e.g. VMX and LMCE) can be used, which is >>>>>>> usually done by the firmware. This patch adds a fw_cfg file >>>>>>> "etc/msr_feature_control" which contains the advised value of >>>>>>> MSR_IA32_FEATURE_CONTROL and can be used by guest firmware (e.g. SeaBIOS). >>>>>>> >>> >>> I'm sorry i'm joining this discussion a bit late returning from vacation. >>> In a real platform supporting LMCE, BIOS is responsible for setting the bits >>> for IA32_FEATURE_CONTROL correctly. There are good reasons why we want the >>> BIOS to play this role. >>> >>> in a virtualized environment, do we really have to push the same requirement >>> or would it suffice to just emulate it as we did in the early patches. >>> >>> Not sure what exact problem is created by just simply supporting it within >>> kvm/qemu and not needing the bios for the guest to also adapt these changes. >> >> At the moment, my understanding of this feature is superficial, but the >> mechanisms involved in it don't seem complex. I don't expect >> difficulties implementing it, I just need the details that I asked for >> spelled out for me. >> >> As to why we should be doing this in the guest firmware(s) -- "because >> that's what happens on physical machines too" :) Following the phys >> world to the letter in virt is not always a goal, but it's never wrong. > > But the guest bios does nothing like the BIOS in the real platform. That's overstated. The guest firmwares do a lot of things they also do on physical hardware. PCI enumeration / resource assignment, for example. > for e.g. a real bios would have SMM handlers to work for implementing firmware > first mechanisms before notifying the OS. None of these exist in the > virtalized world. Both SeaBIOS and OVMF utilize SMM, for various purposes. OVMF's goals with SMM are briefly documented here: . For SMM support, all of KVM, QEMU, and OVMF needed (many) patches. Anyway, I'm neutral on this. If the consensus is that the MSR at hand is none of the guest firmware's business, I won't object -- hey, it's only less work for me. OTOH, if the consensus is that SeaBIOS should be aware of the MSR, then it follows that so should OVMF. Thanks Laszlo