qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2] PAM: make PAM emulation closer to documentat


From: Ефимов Василий
Subject: Re: [Qemu-devel] [PATCH v2] PAM: make PAM emulation closer to documentation
Date: Wed, 9 Sep 2015 15:03:06 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

07.09.2015 15:50, Paolo Bonzini пишет:

Hi Vasily,

I agree that this patch is an improvement compared to the earlier
versions, but it's still a bit of an abstraction violation and I'm not
sure if it works with KVM.
It does not work with KVM. BIOS freezes on 0xCAA26 on
mov %ax,%es
instruction (according to QEMU disassembler).

Last debug messages are:

Booting from ROM...
Booting from ca80:003c

So, a lot of BIOS code is executed. I will investigate the problem.

Let's see if we can improve things.  Please correct me on the following:

1) For the "Make current PAM region a ROM" case, we can get the
ram_addr_t directly from the pc.bios and pc.rom MemoryRegions, and poke
into pam->region[1] and pam->region[2] when we create them.
Yes, we can. But what if another region is at the address? The -pflash
option is an example.

By default and with -bios option mtree is:

address-space: memory
  0000000000000000-ffffffffffffffff (prio 0, RW): system
    0000000000000000-0000000007ffffff (prio 0, RW): alias ram-below-4g
                               @pc.ram 0000000000000000-0000000007ffffff
    0000000000000000-ffffffffffffffff (prio -1, RW): pci
      00000000000c0000-00000000000dffff (prio 1, RW): pc.rom
      00000000000e0000-00000000000fffff (prio 1, R-): alias isa-bios
                              @pc.bios 0000000000020000-000000000003ffff
      00000000fffc0000-00000000ffffffff (prio 0, R-): pc.bios

With -pflash option mtree is:

address-space: memory
  0000000000000000-ffffffffffffffff (prio 0, RW): system
    0000000000000000-0000000007ffffff (prio 0, RW): alias ram-below-4g
                               @pc.ram 0000000000000000-0000000007ffffff
    0000000000000000-ffffffffffffffff (prio -1, RW): pci
      00000000000c0000-00000000000dffff (prio 1, RW): pc.rom
      00000000000e0000-00000000000fffff (prio 1, R-): isa-bios
    00000000fffc0000-00000000ffffffff (prio 0, R-): system.flash0

There is significant difference about isa-bios at least.

In general, new PAM redirects access to region at the address but
not exactly to pc.bios/isa-bios or pc.rom.

In other words, I suggest more generic solution.

We also can set up redirection at machine initialization, but using of
listener makes sure redirection is actual at runtime. I do not know
case in which regions at the PAM addresses are changed dynamically
during guest work. But even during machine initialization the memory
tree is changed multiple times. So, listener at least ensures the last
version of tree is used for redirection choice.

2) For the "Make current PAM region an I/O region" case, you could add
an IOMMU region that to 0xc0000-0xfffff.  The listener would disable
pam->region[1] if address_space_translate returns an I/O region and
enable it if it returns RAM/ROM.
As I see, IOMMU cannot be used for CPU access to memory because of
assertion (!section->mr->iommu_ops) in
exec.c: address_space_translate_for_iotlb
IOMMU is used for redirection of device and debug access through
address_space_translate. Please correct me if I miss something.
However, I cannot understand or
remember what is the case where you get an I/O region.
There is no known case in which an I/O region is at PAM addresses.
But it is theoretically possible. Hence, I decide to implement it
instead of insert an assertion. Also note, the code also covers
case of simple container memory region at the address.

Paolo





reply via email to

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