qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [V12 3/4] hw/i386: Introduce AMD IOMMU


From: Jan Kiszka
Subject: Re: [Qemu-devel] [V12 3/4] hw/i386: Introduce AMD IOMMU
Date: Mon, 4 Jul 2016 07:57:48 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2016-07-04 07:49, David Kiarie wrote:
>>>>> +/* FIXME: something might go wrong if System Software writes in chunks
>>>>> + * of one byte but linux writes in chunks of 4 bytes so currently it
>>>>> + * works correctly with linux but will definitely be busted if software
>>>>> + * reads/writes 8 bytes
>>>>
>>>> What does the spec tell us about non-dword accesses? If they aren't
>>>> allowed, filter them out completely at the beginning.
>>>
>>> Non-dword accesses are allowed. Spec 2.62
>>>
>>> ".... Accesses must be aligned to the size of the access and the size
>>> in bytes must be a power
>>> of two. Software may use accesses as small as one byte..... "
>>>
>>> Linux uses dword accesses though but even in this case a change in the
>>> order of access whereby the high part of the register is accessed
>>> first then the lower accessed could cause a problem (??)
>>
>> I do not get yet what makes it tricky to support all allowed access
>> sizes. You are just missing byte access, and that will easy to add once
>> the size dispatching is done in a single function like suggested below.
> 
> It is tricky because I need to ready some values that may span across
> 1,2,4-byte boundaries and I don't have a way to tell that software is
> done writing. The current logic is based on the assumption that
> software writes the low bytes first which is mostly the case but might
> not always be the case.

According to the spec, software is allowed to read or write any byte,
word, dword and qword, provided it is naturally aligned. Just model that
access, nothing more. If a high-word/byte access triggers some side
effect, than that is what it does (and probably a reason why Linux
avoids it).

Jan


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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