qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Help writing a trivial device


From: Lluís Vilanova
Subject: Re: [Qemu-devel] Help writing a trivial device
Date: Mon, 26 Sep 2011 20:03:12 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Lluís Vilanova writes:

> Stefan Hajnoczi writes:
>> On Mon, Sep 26, 2011 at 12:23:21AM +0200, Lluís Vilanova wrote:
>>> 1) Cannot start QEMU with KVM when the device is enabled:
>>> kvm_set_phys_mem: error registering slot: Invalid argument
>>> 
>>> 2) The driver never gets called on a read/write to its memory

>> If I add #include "pci.h" at the top of the file, change
>> TARGET_PAGE_SIZE to 4096 (generic device code is not supposed to be
>> target-dependent), and throw foo.o into Makefile.objs it builds here.

>> It launches successfully with -enable-kvm and I can see the device
>> inside a VM.  My qemu.git/HEAD is
>> 1ce9ce6a6184f0192015ba9adf1123d89cd47a7b.

> Well, my intent is to implement the backdoor communication channel I rambled
> about some time ago. Now, instead of overloading some unused opcodes, I use a
> virtual device that is target agnostic (as someone wisely suggested).

> As the device is mmap'ed into userspace to interact with it, I thought it made
> sense to use TARGET_PAGE_SIZE to establish the device's mappable ranges.

> Note that the device is not compiled with all the libhw code, so
> TARGET_PAGE_SIZE is not poisoned.

> In any case, now I've just seen that the code I sent does indeed (almost)
> work... the offending code is in the part I did not send. The second bar uses 
> a
> simple malloc'ed piece of data that the user can use as a scratchpad for the
> communication with QEMU, so that the flow is:

>   - guest writes data into data channel
>   - guest writes anything into the control channel
>   - do in QEMU whatever is encoded in the data channel

> It is the second bar that generates the problems with KVM:

s-> data_ptr = g_malloc(s->size);
>     memory_region_init_ram_ptr(&s->data, &s->dev.qdev, "backdoor.data",
s-> size, s->data_ptr);
>     pci_register_bar(&s->dev, 1, PCI_BASE_ADDRESS_SPACE_MEMORY, &s->data);


>> I only had a few minutes and couldn't test reading from BAR0, but you
>> might want to get 32-bit reads working first before trying 64-bit.

> The next problem is using 64bit reads and writes... if I set min_access_size 
> and
> max_access_size to 4, I get the calls to 'control_io_read', but not with 8...

> I've attached the real code I'm using, just to make it easier to test.

Sorry, I forgot the attachment.

The attached virtual device is just a proxy to the user-provided functions
'qemu_backdoor_init' and 'qemu_backdoor', which implement the semantics of the
backdoor channel.

The code in "#if 1" is the piece that offends KVM.


Thanks,
   Lluis


Attachment: softmmu.c
Description: Text document

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

reply via email to

[Prev in Thread] Current Thread [Next in Thread]