[Top][All Lists]

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

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

From: Zhi Yong Wu
Subject: Re: [Qemu-devel] Help writing a trivial device
Date: Tue, 27 Sep 2011 14:15:16 +0800

2011/9/26 Lluís Vilanova <address@hidden>:
> 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:
It can work in my env with the codes below, and i can see the device.
But it is pity that i don't know to test the two bar.

>    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.
> Thanks a lot,
>    Lluis
> --
>  "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


Zhi Yong Wu

reply via email to

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