Hi Amit,
Please correct me if I am wrong, but the fact that the PVDMA module is located in the guest imposes a security problem. So, if someone in the guest has root access, he could modify the PVDMA module and then corrupt the host memory. Because of this the guest has to be trusted. I had an idea that I would like to check with you to see if this is feasible.
What if I need pci passthrough in a known hardware platform where I know all the pci hardware devices, could I intercept the DMA commands to these PCI devices at qemu level and then do the translation from pseudo physical to physical memory address at that level? Since I know which are the devices present in the platform, I also know which are the PCI commands to configure the DMA transfers in the PCI device. Before forwarding this to the real PCI I could change the memory address to a physical one.
Do you think this is possible?
Thanks,
Pablo
>-----Original Message-----
>From: kvm-owner@xxxxxxxxxxxxxxx [mailto:kvm-owner@xxxxxxxxxxxxxxx] On
>Behalf Of Amit Shah
>Sent: Friday, May 15, 2009 10:38 AM
>To: Passera, Pablo R
>Cc: kvm@xxxxxxxxxxxxxxx
>Subject: Re: Status of pci passthrough work?
>
>On (Fri) May 15 2009 [07:14:05], Passera, Pablo R wrote:
>> Hi Amit,
>> Thanks for your answer. I was able to get your userspace pvdma
>version. So now, I am using the PVDMA patched kernel and the PVDMA
>patches userspace. However, I am not able to start the VM. I am running
>qemu with the following options (I am trying without any pci passthrough
>first)
>>
>> ./qemu/x86_64-softmmu/qemu-system-x86_64 -hda /root/kvm/dm2.img -m 256
>-net none
>>
>> The SDL windows appear but it hangs after showing the message "Press
>F12 for boot menu.". I am not getting any message neither in qemu nor in
>dmesg. Do you know what could be happening? May be a kernel compile
>option? It would be great if you can send me the .config file that you
>used to compile it, just to check the options.
>
>Can you try out a few things, like booting off the 'avi' branch in
>userspace and / or the 'kvm' branch of the kernel tree? Just to rule out
>the bugs in the device assignment code.
>
> Amit
>--
>To unsubscribe from this list: send the line "unsubscribe kvm" in
>the body of a message to majordomo@xxxxxxxxxxxxxxx
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
