From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chen, Tiejun" Subject: Re: [PATCH 2/2] mwait_idle: Broadwell support Date: Fri, 17 Oct 2014 09:22:56 +0800 Message-ID: <54406F70.7050501@intel.com> References: <1410180127-4812-1-git-send-email-ross.lagerwall@citrix.com> <1410180127-4812-2-git-send-email-ross.lagerwall@citrix.com> <543FC00C.3050708@intel.com> <543FECE8020000780003F43A@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <543FECE8020000780003F43A@mail.emea.novell.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: Jan Beulich Cc: Ross Lagerwall , Xen-devel , Keir Fraser , len.brown@intel.com List-Id: xen-devel@lists.xenproject.org On 2014/10/16 22:06, Jan Beulich wrote: >>>> On 16.10.14 at 14:54, wrote: >> Did you guys validate this in real machine? Or any potential side affect? >> >> When I do IGD GFX passthrough with qemu-xen-traditional, I found in the >> boot phase of VM, the target will reboot. After I revert this everything >> is fine. > > Please be more precise. What is "target" here? Host? Guest? The real target is BDW based on stepping E. When I use qemu-xen-traditional to validate IGD passthrough like this, gfx_passthru=1 pci=["00:02.0", "00:14.0"] Here the device at "00:02.0" is IGD device, another is USB controller. And we should pass 'no-sharept' to disable shared EPT table since you know there is a well-know RMRR problem I'm trying to fix. During the Windows7 guest VM boot phase, the physical machine reboot directly. > Also, reporting issues just verbally (i.e. without any logs or other > actual technical information) rarely makes a lot of sense. As I said above the machine reboot directly. I can't see any output. > >> Note I don't add anything into codes. Here I just build Xen unstable 4.5 >> to use qemu-xen-traditional. And additionally, my BDW is based on >> stepping E, and guest is WindXP. Any other technical information you guys want to know? > > But the change is only about C-state handling for a particular > CPU model. There's really nothing being added that doesn't > already work fine elsewhere. I.e. this patch being the apparent > culprit of a problem you see makes it relatively likely that your > hardware is having some issue. Yes I also suspect this point but I tried two machine, I still can see the same problem. Maybe this is related to CPU stepping, BIOS or some errata we may ignore previously. So I just post this to ask if anybody know this in detail. Thanks Tiejun > > Jan > >