Come aggiungere un nuovo dispositivo nel codice sorgente QEMU?

Question

Quale potrebbe essere l'approccio graduale per emulare/aggiungere un nuovo dispositivo in qemu utilizzando l'approccio QOM?

Quali e dove potrebbero essere le modifiche rispetto a DeviceState/BusState e altre proprietà?

Answer 1

ci sono alcune parti di esempio in "QOM esegesi e apocalisse" 2014 presentazione a http://events.linuxfoundation.org/sites/events/files/slides/kvmforum14-qom_0.pdf

Creazione di un oggetto

Object *o = object_new(TYPE_RNG_BACKEND_RANDOM); 
object_property_set_str(o, "filename", "/dev/random", NULL); 
object_property_set_bool(o, "opened", "true", NULL); 
object_property_add_child(container_get("/somewhere"), "my-rng", o, NULL); 
object_unref(o); 

proprietà All'interno

static bool rng_get_opened(Object *obj, Error **errp) 
{ 
    RngBackend *s = RNG_BACKEND(obj); 
    return s->opened; 
} 
static void rng_set_opened(Object *obj, bool value, Error **errp) 
{ 
    RngBackend *s = RNG_BACKEND(obj); 
    RngBackendClass *k = RNG_BACKEND_GET_CLASS(s); 
    ... 
    if (k->opened) { 
     k->opened(s, errp) 
    } 
} 
static void rng_backend_init(Object *obj) 
{ 
    object_property_add_bool(obj, "opened", 
     rng_get_opened, rng_set_opened, NULL); 
} 
static const TypeInfo rng_backend_info = { 
    .name = TYPE_RNG_BACKEND, 
    .parent = TYPE_OBJECT, 
    .instance_size = sizeof(RngBackend), 
    .instance_init = rng_backend_init, 
    .class_size = sizeof(RngBackendClass), 
    .abstract = true, 
}; 

(confrontare con codice effettivo: http://code.metager.de/source/xref/qemu/backends/rng.c e un impl ementation di RNG_BACKEND http://code.metager.de/source/xref/qemu/backends/rng-random.c)

Queste due pagine può essere utile anche: * http://wiki.qemu.org/Features/QOM * http://wiki.qemu.org/QOMConventions

Il post "Essential QEMU PCI API" di Siro Mugabi: http://nairobi-embedded.org/001_qemu_pci_device_essentials.html (http://web.archive.org/web/20151116022950/http://nairobi-embedded.org/001_qemu_pci_device_essentials.html) presenta esempio completo di Qom abilitati Driver PCI.

QEMU Object Model (QOM) fornisce un framework per la registrazione di tipi creabili dall'utente. QOM modella bus, interfacce, dispositivi, ecc. Come tipi. In QOM, le informazioni di un utente Type vengono utilizzate per creare l'istanza ObjectClass e l'istanza Object. Questa informazione è specificata in una struttura TypeInfo (include/qom/object.h). Ad esempio:

/* hw/misc/pci-testdev.c */ 

static const TypeInfo pci_testdev_info = { 
     .name   = TYPE_PCI_TEST_DEV, 
     .parent  = TYPE_PCI_DEVICE, 
     .instance_size = sizeof(PCITestDevState), 
     .class_init = pci_testdev_class_init, 
}; 

dove:

• .name una stringa che indica il tipo di utente.
• .parent una stringa che specifica il tipo da cui deriva questo tipo di utente.
• .instance_size dimensioni dell'istanza dell'oggetto del tipo. La sua allocazione verrà eseguita internamente da QOM. Gli oggetti saranno discussi più dettagliatamente nella sezione Oggetto Instantiation.
• .class_init il gancio del costruttore. Questa funzione sarà responsabile per l'inizializzazione dell'istanza ObjectClass del Type.

Answer 2

edu in-albero dei dispositivi PCI educativo

• https://github.com/qemu/qemu/blob/v2.7.0/hw/misc/edu.c
• https://github.com/qemu/qemu/blob/v2.7.0/docs/specs/edu.txt

E 'molto facile da capire e ben documentato, quindi vi consiglio che si studia esso.

Espone un dispositivo PCI minimo, con IO di base, generazione di interrupt e DMA.

Ho scritto un minimo di test dei moduli del kernel di Linux + userland per giocare con esso a:

• https://github.com/cirosantilli/linux-kernel-module-cheat/blob/6788a577c394a2fc512d8f3df0806d84dc09f355/rootfs_overlay/pci.sh
• https://github.com/cirosantilli/linux-kernel-module-cheat/blob/6788a577c394a2fc512d8f3df0806d84dc09f355/kernel_module/pci.c

dispositivo PCI Minimal

I' ho ridotto al minimo edu anche oltre un quarto delle dimensioni sulla mia forcella QEMU: https://github.com/cirosantilli/qemu/blob/22e7e210d6fbe54c35a5ae32450a4419df25a13b/hw/misc/lkmc_pci_min.c No DMA.

conducente del kernel: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/1cd55ebf53542208f7a614a856066123b93d303d/kernel_module/pci_min.c

mio Buildroot involucro integra già la forcella QEMU con un modulo, basta clonare e ./run.

dispositivo piattaforma ARM TYPE_SYS_BUS_DEVICE

SoC-terra cuoce maggior parte dei dispositivi in ​​silicio anziché PCI, ecco un minimo esempio eseguibile:

• QEMU forcella:
  • dispositivo https://github.com/cirosantilli/qemu/blob/144ea94d710c666babd06ed733007377e132ed4a/hw/misc/lkmc_platform_device.c
  • inserire dispositivo in -M versatilepb: https://github.com/cirosantilli/qemu/blob/144ea94d710c666babd06ed733007377e132ed4a/hw/arm/versatilepb.c#L302 Utilizza sysbus_create_simple, che prevede un dispositivo di tipo TYPE_SYS_BUS_DEVICE.
• modulo kernel: https://github.com/cirosantilli/linux-kernel-module-cheat/blob/05fa0105eaccf37d6a675f9b2bae833fd78d4270/kernel_module/platform_device.c Scrive sulla memoria su probe per verificare le cose, che genera anche un IRQ.
• Linux versatile cerotto DTS: https://github.com/cirosantilli/linux/blob/361bb623671a52a36a077a6dd45843389a687a33/arch/arm/boot/dts/versatile-pb.dts#L42
  • informa il kernel in cui si trovano i registri e IRQ, e corrisponde ai parametri di QEMU versatilepb.c
  • compatible corrisponde il platform_driver.name nel modulo del kernel, e informa il kernel quale modulo gestirà questo dispositivo.
  • passato al firmware di QEMU con -dtb

La forcella Linux con la modifica DTC è un modulo di wrapper repo Buildroot, quindi basta clonare e ./run -a arm.

Out-of-albero di dispositivi

ho chiesto se sia possibile realizzare dispositivi out-of-albero a: How to create out-of-tree QEMU devices? ma non sembra esso.