Gleb Natapov wrote on 2013-03-20: > On Wed, Mar 20, 2013 at 11:47:49AM +0000, Zhang, Yang Z wrote: >> Gleb Natapov wrote on 2013-03-20: >>> On Tue, Mar 19, 2013 at 12:27:38PM -0300, Marcelo Tosatti wrote: >>>> On Tue, Mar 19, 2013 at 12:19:55PM -0300, Marcelo Tosatti wrote: >>>>> See the previous argument: should never enter guest mode with PIR ON >>>>> bit set. With logic above: >>>>> >>>>> context1 context2 context3 >>>>> set_bit(PIR-1) >>>>> r = pi_test_and_set_on() set_bit(PIR-40) >>>>> set_bit(KVM_REQ_EVENT) >>>>> if (kvm_check_request(KVM_REQ_EVENT) >>>>> if (test_and_clear_bit(on)) >>>>> kvm_apic_update_irr() r = >>> pi_test_and_set_on() >>>>> >>>>> guest entry with PIR ON=1 >>>>> >>>>> >>>>> Thats the reason for unconditional clearing on guest entry: it is easy >>>>> to verify its correct. I understand and agree the callback (and VMWRITE) >>>>> is not nice. >>>> >>>> Re: KVM_REQ_EVENT setting after set_bit(KVM_REQ_EVENT) assures no >>>> guest entry with PIR ON=1. >>>> >>>> Might be, would have to verify. Its trickier though. Maybe add a FIXME: >>>> to the callback and remove it later. >>> We have time still. RTC series is not ready yet. I'll think hard and try >>> to poke holes in the logic in this patch and you do the same for what I >>> propose. >> Any thought? As far as I see, the two solutions are ok. It's hard to say which is > better. But clear ON bit when sync_pir_irr should be more clear and close to > hardware's behavior. >> > Lets go with it unless we see why it will not work. Sure. Best regards, Yang -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
