Re: [Qemu-devel] [PATCH] pci: Length-align config space accesses

[Jan Kiszka]

On 2011-07-20 18:45, Michael S. Tsirkin wrote:
> On Wed, Jul 20, 2011 at 06:18:43PM +0200, Jan Kiszka wrote:
>> On 2011-07-20 18:17, Isaku Yamahata wrote:
>>> On Wed, Jul 20, 2011 at 04:27:08PM +0200, Jan Kiszka wrote:
>>>> On 2011-07-20 14:15, Jan Kiszka wrote:
>>>>> On 2011-07-20 14:00, Isaku Yamahata wrote:
>>>>>> Hi. This clean up looks good basically.
>>>>>
>>>>> Oops, forgot to cc you. Sorry.
>>>>>
>>>>>> But when conventional pci device is accessed via MMCONFIG area,
>>>>>> addr &= addr_mask doesn't work as expected.
>>>>>> The config area of [256, 4K) of conventional pci should have no effect.
>>>>>
>>>>> Mmh, I see. Looks like we need to split accesses at this boundary and
>>>>> executed them separately.
>>>>
>>>> Nope, no such issue: we already automatically split up accesses that
>>>> span the legacy/extended boundary. Just like so far, legacy config space
>>>> handlers have to filter out requests that address regions >= 256.
>>>
>>> For example, when accessing to offset 257 of conventional pci device,
>>> the access is routed to offset 1 due to the masking.
>>> Such overwrapping isn't correct.
>>
>> No, it isn't routed like that. The mask used via mmio is 0xfff.
>>
>> Jan
> 
> I thought about this some more, I'd like to see how devices
> are going to benefit. Any examples?

No in-tree device currently gets beyond the "write default, check range"
pattern.

> If not, is it easier to simply make this logic
> part of dev assignment?

That's a question of clean interfaces. Not checking at the core means
exposing invalid accesses to the callbacks.

The logic is required anyway, so better put it in a central place. E.g.
if the Xen people push their device assignment as well, we will suddenly
have more than one user.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux