qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Ефимов Василий" <real@ispras.ru>, qemu-devel@nongnu.org
Cc: Kirill Batuzov <batuzovk@ispras.ru>,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 3/3] PAM: make PAM emulation closer to documentation
Date: Thu, 16 Jul 2015 19:52:23 +0200	[thread overview]
Message-ID: <55A7EF57.4080306@redhat.com> (raw)
In-Reply-To: <55A7C2A9.6040902@ispras.ru>



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	other threads:[~2015-07-16 17:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-16  8:35 [Qemu-devel] [PATCH 0/3] PAM emulation improvement Efimov Vasily
2015-07-16  8:35 ` [Qemu-devel] [PATCH 1/3] memory: make function invalidate_and_set_dirty public Efimov Vasily
2015-07-16  8:35 ` [Qemu-devel] [PATCH 2/3] memory: make function memory_access_is_direct public Efimov Vasily
2015-07-16  8:35 ` [Qemu-devel] [PATCH 3/3] PAM: make PAM emulation closer to documentation Efimov Vasily
2015-07-16  9:05   ` Paolo Bonzini
2015-07-16 10:51     ` Ефимов Василий
2015-07-16 11:10       ` Paolo Bonzini
2015-07-16 14:41         ` Ефимов Василий
2015-07-16 17:52           ` Paolo Bonzini [this message]
2015-07-17  9:50             ` Ефимов Василий
2015-07-17 10:10               ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55A7EF57.4080306@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=batuzovk@ispras.ru \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=real@ispras.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).