On Thu, Jun 14, 2018 at 5:22 PM, Stuart Hayes <stuart.w.hayes@xxxxxxxxx> wrote:
> On 6/13/2018 3:54 AM, Andy Shevchenko wrote:
>>> + * Provide physical address of command buffer field within
>>> + * the struct smi_cmd... can't use virt_to_phys on smi_cmd
>>> + * because address may be from memremap.
>>
>> Wait, memremap() might return a virtual address. How we be sure that
>> we got still physical address here?
> Before this patch, the address in smi_cmd always came from an alloc, so
> virt_to_phys() was used to get the physical address here. With WSMT, we
> could be using a BIOS-provided buffer for SMI, in which case the address in
> smi_cmd will come from memremap(), so we can't use virt_to_phys() on it.
> So instead I changed this to use the physical address of smi_data_buf that
> is stored in smi_data_buf_phys_addr, which will be valid regardless of how
> the address of smi_data_buf was generated.
Yes, but what does guarantee that memremap() will return you still
physical address?
>>> + return 0;
>>> +
>>> + /* Scan for EPS (entry point structure) */
>>> + for (addr = (u8 *)__va(0xf0000);
>>> + addr < (u8 *)__va(0x100000 - sizeof(struct smm_eps_table));
>>
>>> + addr += 1) {
>>
>> This wasn't commented IIRC and changed. So, why?
> I changed this is response to your earlier comment (7 june)... you had pointed
> out that it would be better if I put an "if (eps) break;" inside the for loop
> instead of having "&& !eps" in the condition of the for loop. I put the note
> "Changed loop searching 0xf0000 to be more readable" in the list of changes for
> patch version v3 to cover this change.
Thanks, but here I meant += 1 vs += 16 step.
--
With Best Regards,
Andy Shevchenko
