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 14:07:36 +0200 Message-ID: <51D41408.8070909@redhat.com> References: <51D42A7402000078000E276F@nat28.tlf.novell.com> <51D40EDB.70204@redhat.com> <51D42F1502000078000E27AE@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <51D42F1502000078000E27AE@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 14:03, Jan Beulich ha scritto: >>>> On 03.07.13 at 13:45, Paolo Bonzini wrote: >> 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? > > No: > > static int hpet_range(struct vcpu *v, unsigned long addr) > { > return (v->domain->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] && > (addr >= HPET_BASE_ADDRESS) && > (addr < (HPET_BASE_ADDRESS + HPET_MMAP_SIZE))); > } Ah, I meant with hpet=1. Of course if hpet=0 qemu shouldn't emulate it or should be told not to emulate it. The idea of the patch was that anyway Device(HPET) is disabled in the ACPI table if the hpet is disabled. But if old Linux guests cannot cope with this, too bad... Paolo