I think the use-case for this is to allow passthrough device with level-triggered IRQ to an *untrusted* guest. This is because once device asserted IRQ line, only guest can program it to de-assert it and therefore, host cannot just EOI device IRQ vector in physical LAPIC. (2/6)
-
-
Prikaži ovu nit
-
Therefore, IER is provided to allow keeping vector not-acked by guest while still not blocking lower vectors from being raised when running other guests or host. However, this made me wonder how exactly vfio-pci handles this in case on Intel CPUs... (3/6)
Prikaži ovu nit -
Turns out vfio-pci relies on generically causing device to de-assert IRQ line by manipulating PCI config space DisINTx bit. Thus, host can just EOI physical LAPIC immediately after host INTx handler sets DisINTx bit. This is done regardless if running on Intel or AMD CPU... (4/6)
Prikaži ovu nit -
This leads me to wonder on several questions... Question 1: Did AMD really created this entire IER LAPIC hardware feature because they just haven't thought about this DisINTx trick?! Or is it because some devices don't support DisINTx bit? (5/6)
Prikaži ovu nit -
Question 2: http://vfio.blogspot.com/2014/09/vfio-interrupts-and-how-to-coax-windows.html … states that for non-PCI-2.3 compliant devices: "we can mask the interrupt at the system APIC rather than at the device itself". How? By EOI when EFLAGS.IF=0 and then manually set IOAPIC redir-tbl entry remote_irr before re-set EFLAG.IF to 1?
Prikaži ovu nit -
@fagiolinux@blitzclone@dwmw2@mjg59@_msw_@anliguori You probably have better insights than me on this... Do you happen to know the answers to these questions?Prikaži ovu nit -
Novi razgovor -
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.