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