On 26/06/2015 02:26, Steve Rutherford wrote: > Implemented a basic version of this, and ran into some potential > issues with this strategy. Supporting PIC masking/unmasking by the > CPU/APIC means that either: > A) PIC interrupts need to be bufferable in the kernel (with some way > of comparing priorities). > B) the APIC state needs to be read in order to fetch the bit as to > whether or not the PIC is being masked (which I believe can be done > from userspace via the APIC state ioctl). > C) something hacky that doesn't conform to the PIC spec but still > happens to boot common OSes (like buffering the interrupts and > injecting them in the order of arrival (which is wrong)). I think B is okay to do. Later if needed we can make it possible for userspace to mmap the LAPIC page instead of using the APIC state ioctl. Paolo -- 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
