[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v2] exec: Fix MAP_RAM for cached access

From: Auger Eric
Subject: Re: [Qemu-devel] [PATCH v2] exec: Fix MAP_RAM for cached access
Date: Thu, 14 Jun 2018 09:24:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

Hi Peter,

On 06/14/2018 03:52 AM, Peter Xu wrote:
> On Wed, Jun 13, 2018 at 04:20:34PM +0200, Auger Eric wrote:
>> Hi Paolo,
>> On 06/13/2018 03:53 PM, Paolo Bonzini wrote:
>>> On 13/06/2018 15:44, Auger Eric wrote:
>>>>> Queuing this patch.  I'm not sure how I missed this, I have actually
>>>>> tested it with SMMU.
>>>> no problem. Strange also I was the only one facing the issue.
>>> No, I must have blundered it between testing and posting the patches.
>>>>> Do you also need the MemTxAttrs so that the right PCI requestor id is
>>>>> used, or do you get it from somewhere else?
>>>> which call site do you have in mind, sorry?
>>> I'm wondering if the MemoryRegionCache needs to store the MemTxAttrs.
>>> They would be passed to address_space_init_cache.
>> I acknowledge I don't master this code enough but I would say MSI
>> wouldn't work already (vITS wouldn't translate them properly) if the
>> proper requester_id wasn't conveyed properly. MSI writes to the doorbell
>> are not cached I guess?
> I might be wrong, but I guess Paolo means the DMA part.  In
> address_space_cache_init() now we are with MEMTXATTRS_UNSPECIFIED when
> translate the first time (to be cached).
Ah OK, I was focused on the requester_id mention.
> But I'd also guess we're fine with that now since after all we're not
> even passing the attrs into IOMMUMemoryRegionClass.translate() yet.
OK fine. This can be added later on then.



> Regards,

reply via email to

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