On Tue, Apr 22, 2014 at 04:26:48PM -0300, Marcelo Tosatti wrote: > On Tue, Apr 22, 2014 at 12:11:47PM +0300, Michael S. Tsirkin wrote: > > On Mon, Apr 21, 2014 at 06:40:17PM -0300, Marcelo Tosatti wrote: > > > On Sun, Apr 13, 2014 at 04:10:22PM +0300, Michael S. Tsirkin wrote: > > > > It seems that it's easy to implement the EOI assist > > > > on top of the PV EOI feature: simply convert the > > > > page address to the format expected by PV EOI. > > > > > > > > Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx> > > > > > > Looks alright except: > > > > > > - There is no handling of PV EOI data to be performed at HV_X64_MSR_EOI write > > > path? I thought HV_X64_MSR_EOI is a separate optimization - it's an X2APIC replacement that lets you do EOI with an MSR and not IO. No? > > > - Migration fails with PV-EOI not enabled in CPUID ? (perhaps could > > > require it for PV-EOI over HV-APIC-ASSIST). Did not try migration yet - could you explain the issue please? HV-APIC-ASSIST MSR is in the list of saved MSRs ... > > > - MS docs mention "No EOI required" is set only if interrupt injected is edge > > > triggered. > > > > Hmm I thought level interrupts are going through IOAPIC so that's already true isn't it? > > > > if (!pv_eoi_enabled(vcpu) || > > /* IRR set or many bits in ISR: could be nested. */ > > apic->irr_pending || > > /* Cache not set: could be safe but we don't bother. */ > > apic->highest_isr_cache == -1 || > > ---> /* Need EOI to update ioapic. */ > > kvm_ioapic_handles_vector(vcpu->kvm, apic->highest_isr_cache)) { > > Right. > > > /* > > * PV EOI was disabled by apic_sync_pv_eoi_from_guest > > * so we need not do anything here. > > */ > > return; > > } > > > > In any case if some interrupt handler ignores this bit because it's > > level, that's harmless since it will do EOI and then we'll clear the > > bit, right? > > Yes. -- 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