qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 3/3] PAM: make PAM emulation closer to documenta


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 3/3] PAM: make PAM emulation closer to documentation
Date: Thu, 16 Jul 2015 19:52:23 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1


On 16/07/2015 16:41, Ефимов Василий wrote:
> The main problem is rendering memory tree to FlatView.

I don't believe it's necessary to render a memory tree to the FlatView.
 You can use existing AddressSpaces.

>> +    /* Read from RAM and write to PCI */
>> +    memory_region_init_io(&pam->region[1], OBJECT(dev), &pam_ops, pam,
>> +            "pam-r-ram-w-pci", size); 
>>
>> This can be done with memory_region_set_readonly on the RAM region.  You
>> need to set mr->ops in order to point to pam_ops; for a first proof of
>> concept you can just set the field directly.
> The idea is to read directly from system RAM region and to write
> to PCI using I/O (because I do not see another way to emulate
> access type driven redirection with existent API). If we create RAM
> and make it read only then new useless RAM block will be created.

Don't create RAM; modify the existing one.

> It is useless because of ram_addr of new region will be set to
> one within system RAM block. Hence, cleaner way is to create I/O region.

You can use the existing RAM region and modify its properties (i.e.
toggle mr->readonly) after setting special mr->ops.  The special mr->ops
will be used for writes when mr->readonly = true.

>> Writes to the PCI memory space can use the PCI address space, with
>> address_space_st*.
> There is no PCI AddressSpace (only MemoryRegion). But
> address_space_st* requires AddressSpace as argument.

Then create one with address_space_init.

However, can the guest see the difference between "real" mode 1 and the
"fake" mode 1 that QEMU implements?  Perhaps mode 1 can be left as is.

>> +    /* Read from PCI and write to RAM */
>> +    memory_region_init_io(&pam->region[2], OBJECT(dev), &pam_ops, pam,
>> +            "pam-r-pci-w-ram", size);
>>
>> Here you cannot run code from ROM, so it can be a pure MMIO region.
>> Reads can use address_space_ld*, while writes can use
>> memory_region_get_ram_ptr.
> 
> Even in this mode it is possible for code to be executed from ROM. This
> can happen when particular PCI address is within ROM device connected
> to PCI bus.

If it's just for pc.rom and isa-bios, introduce a new function
pam_create_pci_region that creates pc.rom with
memory_region_init_rom_device.  The mr->ops can write to RAM (mode 2) or
discard the write (mode 0).

They you can make pc.rom 256K instead of 128K, and instead of an alias,
you can manually copy the last 128K of the BIOS into the last 128K of
pc.rom.

Some adjustment will be necessary in order to support migration (perhaps
creating two 128K regions pc.rom and pc.rom.mirror), but for a proof of
concept the above should be enough.

Paolo



reply via email to

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