|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V2 23/25] x86/vvtd: Handle interrupt translation faults
On Wed, Aug 23, 2017 at 12:51:27PM +0100, Roger Pau Monné wrote:
>On Wed, Aug 09, 2017 at 04:34:24PM -0400, Lan Tianyu wrote:
>> From: Chao Gao <chao.gao@xxxxxxxxx>
>>
>> Interrupt translation faults are non-recoverable fault. When faults
> ^ faults
>> are triggered, it needs to populate fault info to Fault Recording
>> Registers and inject vIOMMU msi interrupt to notify guest IOMMU driver
>> to deal with faults.
>>
>> This patch emulates hardware's handling interrupt translation
>> faults (more information about the process can be found in VT-d spec,
>> chipter "Translation Faults", section "Non-Recoverable Fault
> ^ chapter
>> Reporting" and section "Non-Recoverable Logging").
>> Specifically, viommu_record_fault() records the fault information and
>> viommu_report_non_recoverable_fault() reports faults to software.
>> Currently, only Primary Fault Logging is supported and the Number of
>> Fault-recording Registers is 1.
>>
>> Signed-off-by: Chao Gao <chao.gao@xxxxxxxxx>
>> Signed-off-by: Lan Tianyu <tianyu.lan@xxxxxxxxx>
>> ---
>
>> /* Address range of remapping hardware register-set */
>> uint64_t base_addr;
>> uint64_t length;
>> @@ -97,6 +101,23 @@ static inline struct vvtd *vcpu_vvtd(struct vcpu *v)
>> return domain_vvtd(v->domain);
>> }
>>
>> +static inline int vvtd_test_and_set_bit(struct vvtd *vvtd, uint32_t reg,
>> + int nr)
>
>unsigned int for nr, and I'm not really sure the usefulness of this
>helpers. In any case inline should not be used and instead let the
>compiler optimize this.
>
I think compiler doesn't know the frequency of calling these function.
Explicitly make this function inline sometimes can avoid compiler
doesn't do this for some short and frequently used functions.
>> +static void vvtd_report_non_recoverable_fault(struct vvtd *vvtd, int reason)
>> +{
>> + uint32_t fsts;
>> +
>> + ASSERT(reason & DMA_FSTS_FAULTS);
>> + fsts = vvtd_get_reg(vvtd, DMAR_FSTS_REG);
>> + __vvtd_set_bit(vvtd, DMAR_FSTS_REG, reason);
>
>I don't understand this, is reason a bit position or a mask?
>
>DMA_FSTS_FAULTS seems to be a mask, that should be set into DMAR_FSTS_REG?
According VT-d spec 10.4.9, Each kind of fault is denoted by one bit in
DMAR_FSTS_REG.
>> static int vvtd_record_fault(struct vvtd *vvtd,
>> - struct irq_remapping_request *irq,
>> + struct irq_remapping_request *request,
>> int reason)
>> {
>> - return 0;
>> + struct vtd_fault_record_register frcd;
>> + int frcd_idx;
>> +
>> + switch(reason)
>> + {
>> + case VTD_FR_IR_REQ_RSVD:
>> + case VTD_FR_IR_INDEX_OVER:
>> + case VTD_FR_IR_ENTRY_P:
>> + case VTD_FR_IR_ROOT_INVAL:
>> + case VTD_FR_IR_IRTE_RSVD:
>> + case VTD_FR_IR_REQ_COMPAT:
>> + case VTD_FR_IR_SID_ERR:
>> + if ( vvtd_test_bit(vvtd, DMAR_FSTS_REG, DMA_FSTS_PFO_BIT) )
>> + return X86EMUL_OKAY;
>> +
>> + /* No available Fault Record means Fault overflowed */
>> + frcd_idx = vvtd_alloc_frcd(vvtd);
>> + if ( frcd_idx == -1 )
>> + {
>> + vvtd_report_non_recoverable_fault(vvtd, DMA_FSTS_PFO_BIT);
>> + return X86EMUL_OKAY;
>> + }
>> + memset(&frcd, 0, sizeof(frcd));
>> + frcd.fields.FR = (u8)reason;
>> + frcd.fields.FI = ((u64)irq_remapping_request_index(request)) << 36;
>> + frcd.fields.SID = (u16)request->source_id;
>> + frcd.fields.F = 1;
>> + vvtd_commit_frcd(vvtd, frcd_idx, &frcd);
>> + return X86EMUL_OKAY;
>> +
>> + default:
>
>Other reasons are just ignored? Should this have an ASSERT_UNREACHABLE
>maybe?
It can have for all the faults are raised by vvtd. When vvtd generates a
new kinds of fault, the corresponding handler also should be added.
>
>> + break;
>> + }
>> +
>> + gdprintk(XENLOG_ERR, "Can't handle vVTD Fault (reason 0x%x).", reason);
>> + domain_crash(vvtd->domain);
>
>Oh, I see. Is it expected that such faults with unhandled reasons can
>be somehow generated by the domain itself?
>
No. Faults are generated by vvtd. We only add interrupt translation
faults. Other faults can be added when adding other features (e.g. DMA
remapping).
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |