All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: aliguori@us.ibm.com, Alexander Graf <agraf@suse.de>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] cpu_physical_memory_write_rom() needs to do TB invalidates
Date: Wed, 22 Aug 2012 09:05:52 +0200	[thread overview]
Message-ID: <503484D0.6090100@web.de> (raw)
In-Reply-To: <5034807C.8010004@web.de>

[-- Attachment #1: Type: text/plain, Size: 2813 bytes --]

On 2012-08-22 08:47, Jan Kiszka wrote:
> On 2012-08-22 07:57, David Gibson wrote:
>> On Wed, Aug 22, 2012 at 07:55:31AM +0200, Alexander Graf wrote:
>>>
>>> On 22.08.2012, at 06:59, David Gibson wrote:
>>>
>>>> cpu_physical_memory_write_rom(), despite the name, can also be used to
>>>> write images into RAM - and will often be used that way if the machine
>>>> uses load_image_targphys() into RAM addresses.
>>>>
>>>> However, cpu_physical_memory_write_rom(), unlike cpu_physical_memory_rw()
>>>> does invalidate any cached TBs which might be affected by the region
>>>> written.
>>>>
>>>> This was breaking reset (under full emu) on the pseries machine - we loaded
>>>> our firmware image into RAM, and while executing it rewrite the code at
>>>> the entry point (correctly causing a TB invalidate/refresh).  When we
>>>> reset the firmware image was reloaded, but the TB from the rewrite was
>>>> still active and caused us to get an illegal instruction trap.
>>>>
>>>> This patch fixes the bug by duplicating the tb invalidate code from
>>>> cpu_physical_memory_rw() in cpu_physical_memory_write_rom().
>>>>
>>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>>> ---
>>>> exec.c |    7 +++++++
>>>> 1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/exec.c b/exec.c
>>>> index 5834766..eff40d7 100644
>>>> --- a/exec.c
>>>> +++ b/exec.c
>>>> @@ -3523,6 +3523,13 @@ void cpu_physical_memory_write_rom(target_phys_addr_t addr,
>>>>             /* ROM/RAM case */
>>>>             ptr = qemu_get_ram_ptr(addr1);
>>>>             memcpy(ptr, buf, l);
>>>> +            if (!cpu_physical_memory_is_dirty(addr1)) {
>>>> +                /* invalidate code */
>>>> +                tb_invalidate_phys_page_range(addr1, addr1 + l, 0);
>>>> +                /* set dirty bit */
>>>> +                cpu_physical_memory_set_dirty_flags(
>>>> +                    addr1, (0xff & ~CODE_DIRTY_FLAG));
>>>> +            }
>>>
>>> Can't we just call cpu_physical_memory_rw in the RAM case? The
>>> function only tries to not do MMIO accesses on ROM pages, right?
>>
>> Maybe.  It's not clear at all to me what cases
>> cpu_physical_memory_write_rom() is supposed to be for, as opposed to
>> just using cpu_physical_memory_rw().
> 
> write_rom ignores write protection - that you usually find on ROMs. That
> makes no difference under KVM so far as there we lack read-only
> sections. But that will be fixed soon, patches are on the list.

In fact, it does make a difference also for KVM mode as
cpu_physical_memory_rw works from userspace while the limitation only
affects guest code running under KVM control.

Jan

PS: I'm still facing a bogus Mail-Followup-To tag in your postings,
David, thus you easily fall from the To list on reply.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2012-08-22  7:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-22  4:59 [Qemu-devel] [PATCH] cpu_physical_memory_write_rom() needs to do TB invalidates David Gibson
2012-08-22  5:55 ` Alexander Graf
2012-08-22  5:57   ` David Gibson
2012-08-22  6:02     ` Alexander Graf
2012-08-22  6:10       ` David Gibson
2012-08-22  6:12         ` Alexander Graf
2012-08-22  6:31         ` Alexander Graf
2012-08-22  6:47     ` Jan Kiszka
2012-08-22  7:05       ` Jan Kiszka [this message]
2012-08-22 11:38         ` David Gibson
2012-08-22 11:47           ` Alexander Graf
2012-08-22 13:09             ` Avi Kivity
  -- strict thread matches above, loose matches on Subject: below --
2012-09-03  0:58 David Gibson

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=503484D0.6090100@web.de \
    --to=jan.kiszka@web.de \
    --cc=agraf@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.