Re: [Xen-devel] [RFC PATCH 00/23] xen/vIOMMU: Add vIOMMU support with irq remapping fucntion on Intel platform

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Tue, Mar 21, 2017 at 01:29:26PM +0800, Lan Tianyu wrote:
> On 2017年03月21日 10:28, Lan Tianyu wrote:
> > On 2017年03月20日 22:23, Roger Pau Monné wrote:
> >> Thanks! So you add all this vIOMMU code, but the maximum number of allowed
> >> vCPUs for HVM guests is still limited to 128 (HVM_MAX_VCPUS is not 
> >> touched). Is
> >> there any missing pieces in order to bump this?
> > 
> > To increase vcpu number, we need to change APIC ID rule and now it's
> > APICID = VCPUID * 2. Andrew's CPUID improvement will change it and so
> > our following patches of increasing vcpu number will base on Andrew's job.
> > 
> > 
> >>
> >> Also, have you tested if this series works with PVH guests? Boris added PVH
> >> support to Linux not long ago, so you should be able to test it just by 
> >> picking
> >> the latest Linux kernel.
> > 
> > Our patchset just targets hvm guest and it will not work for PV guest. 
> 
> New hypercalls introduced by this patchset also can reuse for PVH to
> enable vIOMMU. This patchset relies on Qemu Xen-vIOMMU device model to
> create/destroy vIOMMU. If we want to enable DMA translation for hvm
> guest later, virtual device's DMA request would be passed from Qemu to
> Xen hypervisor and the device model in Qemu is necessary.

The DMA remapping probably doesn't make sense for PVH because PVH doesn't have
emulated devices, but in any case it would be good to disentangle all this from
the QEMU (device model) code. AFAICT the DMA remapping part would still be
useful when doing PCI-passthrough to a PVH guest, and that doesn't involve
QEMU.

Also, the vIOMMU hypercalls are added as DMOPs, which seems to imply that they
should be used with/from a device model (and this won't be the case for PVH).

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel