On Mon, May 10, 2010 at 9:28 AM, Avi Kivity <avi@xxxxxxxxxx> wrote:
> On 05/10/2010 06:22 PM, Cam Macdonell wrote:
>>
>>>
>>>> +
>>>> + /* if the position is -1, then it's shared memory region fd */
>>>> + if (incoming_posn == -1) {
>>>> +
>>>> + s->num_eventfds = 0;
>>>> +
>>>> + if (check_shm_size(s, incoming_fd) == -1) {
>>>> + exit(-1);
>>>> + }
>>>> +
>>>> + /* creating a BAR in qemu_chr callback may be crazy */
>>>> + create_shared_memory_BAR(s, incoming_fd);
>>>>
>>>>
>>>
>>> It probably is... why can't you create it during initialization?
>>>
>>
>> This is for the shared memory server implementation, so the fd for the
>> shared memory has to be received (over the qemu char device) from the
>> server before the BAR can be created via qemu_ram_mmap() which adds
>> the necessary memory
>>
>>
>
>
> We could do the handshake during initialization. I'm worried that the
> device will appear without the BAR, and strange things will happen. But the
> chardev API is probably not geared for passing data during init.
More specifically, the challenge I've found is that there is no
function to tell a chardev to block and wait for the initialization
data.
>
> Anthony, any ideas?
>
>> Otherwise, if the BAR is allocated during initialization, I would have
>> to use MAP_FIXED to mmap the memory. This is what I did before the
>> qemu_ram_mmap() function was added.
>>
>
> What would happen to any data written to the BAR before the the handshake
> completed? I think it would disappear.
But, the BAR isn't there until the handshake is completed. Only after
receiving the shared memory fd does my device call pci_register_bar()
in the callback function. So there may be a case with BAR2 (the
shared memory BAR) missing during initialization. FWIW, I haven't
encountered this.
>
> So it's a good idea to make the initialization process atomic.
>
> --
> error compiling committee.c: too many arguments to function
>
>
--
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
