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 14:54:10 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

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.


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



reply via email to

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