On 04/08/2010 01:51 AM, Cam Macdonell wrote: (sorry about the late review)
+ +Regular Interrupts +------------------ + +If regular interrupts are used (due to either a guest not supporting MSI or the +user specifying not to use them on startup) then the value written to the lower +16-bits of the Doorbell register results is arbitrary and will trigger an +interrupt in the destination guest.
Does the value written show up in the status register? If yes, it can get overwritten by other interrupts. If not, the lower 16 bits should be reserved to the value 1 for future expansion. Basically it means that the pci interrupt is equivalent to to vector 1.
+ +An interrupt is also generated when a new guest accesses the shared memory +region. A status of (2^32 - 1) indicates that a new guest has joined.
Suggest making this a bitfield, define bit 0 as 'at least some other machine has signalled you' and bit 1 as 'at least one other machine has joined'.
+ +Message Signalled Interrupts +---------------------------- + +A ivshmem device may support multiple MSI vectors. If so, the lower 16-bits +written to the Doorbell register must be between 1 and the maximum number of +vectors the guest supports. The lower 16 bits written to the doorbell is the +MSI vector that will be raised in the destination guest. The number of MSI +vectors can vary but it is set when the VM is started, however vector 0 is +used to notify that a new guest has joined. Guests should not use vector 0 for +any other purpose.
Come to think about it, the guest has joined is actually pointless. Since it hasn't initialized yet you can't talk to it. So it's best to leave it completely to the application, which can initialize shared memory and start sending interrupts. An application defined protocol can handle joining.
How is initialization performed? I guess we can define memory to start zeroed and let participants compete to acquire a lock.
Need to document the mask register. Do we want an interrupt on a guest leaving? Let's not complicate things. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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
