qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] 答复: [BUG] Windows 7 got stuck easily while run PCMark1


From: Hailiang Zhang
Subject: Re: [Qemu-devel] 答复: [BUG] Windows 7 got stuck easily while run PCMark10 application
Date: Sat, 2 Dec 2017 11:29:58 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 2017/12/2 2:37, Paolo Bonzini wrote:
On 01/12/2017 18:45, Gonglei (Arei) wrote:
I also think it's windows bug, the problem is that it doesn't occur on
xen platform.
It's a race, it may just be that RTC PIO is faster in Xen because it's
implemented in the hypervisor.

No, In Xen, it does not has such problem because it injects the RTC irq without
checking whether its previous irq been cleared or not, which we do has such 
checking
in KVM.

static int ioapic_set_irq(struct kvm_ioapic *ioapic, unsigned int irq,
        int irq_level, bool line_status)
{
   ... ...
    if (!irq_level) {
        ioapic->irr &= ~mask; -->clear the RTC irq in irr, Or we will can not 
inject RTC irq.
        ret = 1;
        goto out;
    }

I agree that we move the operation of clearing RTC irq from cmos_ioport_read() 
to
cmos_ioport_write() to ensure the action been done.

Thanks,
Hailiang

I will try reporting it to Microsoft.

Thanks,

Paolo

Thanks,
Gonglei
*发件人:*Paolo Bonzini
*收件人:*龚磊,张海亮,qemu-devel,Michael S. Tsirkin
*抄送:*黄伟栋,王欣,谢祥有
*时间:*2017-12-02 01:10:08
*主题:*Re: [BUG] Windows 7 got stuck easily while run PCMark10 application

On 01/12/2017 08:08, Gonglei (Arei) wrote:
First write to 0x70, cmos_index = 0xc & 0x7f = 0xc
        CPU 0/KVM-15566 kvm_pio: pio_write at 0x70 size 1 count 1 val 0xc> Second write to 
0x70, cmos_index = 0x86 & 0x7f = 0x6>        CPU 1/KVM-15567 kvm_pio: pio_write at 0x70 
size 1 count 1 val 0x86> vcpu0 read 0x6 because cmos_index is 0x6 now:>        CPU 
0/KVM-15566 kvm_pio: pio_read at 0x71 size 1 count 1 val 0x6> vcpu1
read 0x6:>        CPU 1/KVM-15567 kvm_pio: pio_read at 0x71 size 1 count
1 val 0x6
This seems to be a Windows bug.  The easiest workaround that I
can think of is to clear the interrupts already when 0xc is written,
without waiting for the read (because REG_C can only be read).

What do you think?

Thanks,

Paolo

.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]