From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: revert commit e4fd0475 ("hvmloader: always include HPET table") Date: Wed, 03 Jul 2013 13:45:31 +0200 Message-ID: <51D40EDB.70204@redhat.com> References: <51D42A7402000078000E276F@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51D42A7402000078000E276F@nat28.tlf.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: Keir Fraser , xen-devel List-Id: xen-devel@lists.xenproject.org Il 03/07/2013 13:43, Jan Beulich ha scritto: > Windows SVVP tests requiring a HPET ACPI table is in my opinion > not a valid reason to always expose that table - respective tests > should be run with "hpet=1" in the guest config file. > > The problem here is that at least with qemu-traditional, which > by default doesn't appear to emulate a HPET, Isn't the HPET emulated in the hypervisor anyway? > the advertising > here can mislead an OS to believe that there actually is a usable > HPET, which isn't true when neither Xen nor qemu emulate one. > This ie being observed in reality: SLES9, being 2.6.5 based, > doesn't have enough checking to notice that the HPET doesn't > actually work. Fair enough, the oldest I tested at the time was 2.6.9. Paolo > In fact, we may want to have an inverse mode (like a lot of > hardware used to behave earlier on): A functional HPET that > isn't exposed in ACPI tables, but that an OS knowing enough > about the chipset can nevertheless find and use.