From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: Remaining passthrough/VT-d tasks list Date: Sat, 27 Sep 2008 12:09:54 +0200 Message-ID: <48DE0672.4060801@web.de> References: <0122C7C995D32147B66BF4F440D3016301C49E61@pdsmsx415.ccr.corp.intel.com> <200809241431.13571.sheng.yang@intel.com> <48D9FC8B.2040902@redhat.com> <200809271715.54439.sheng.yang@intel.com> <48DE01AB.2050303@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDFB3F6720843C3FD69E61DEF" Cc: "Yang, Sheng" , "Han, Weidong" , "kvm@vger.kernel.org" , Amit Shah , "benami@il.ibm.com" , "muli@il.ibm.com" , "Kay, Allen M" , "Zhang, Xiantao" To: Avi Kivity Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:40758 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752224AbYI0KKB (ORCPT ); Sat, 27 Sep 2008 06:10:01 -0400 In-Reply-To: <48DE01AB.2050303@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDFB3F6720843C3FD69E61DEF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > Yang, Sheng wrote: >> After check host shared interrupts situation, I got a question here: >> >> If I understand correctly, current solution don't block host shared >> irq, just come with the performance pentry. The penalty come with host= >> disabled irq line for a period. We have to wait guest to write EOI. >> But I fail to see the correctness problem here (except a lot of >> spurious interrupt in the guest). >> >> I've checked mail, but can't find clue about that. Can you explain the= >> situation? >> >> =20 >=20 > If the guest fails to disable interrupts on a device that shares an > interrupt line with the host, the host will experience an interrupt > flood. Eventually the host will disable the host device as well. >=20 It's the same issue we have since ages in the real-time domain: You cannot safely share IRQs between devices that are handled partly by RT-safe and partly by RT-unsafe drivers. The only sane solution is to write an RT-safe stub that is able to detect if an IRQ was triggered by the non-RT device, satisfy the IRQ source (disable further IRQ generation in the device), and forward the event to the non-RT driver part for handling the rest later. Transfered to the virtualization domain, you need a host driver stub for each guest device that shares an IRQ with another host device. Maybe there is some generic hardware support for this in recent PCI or in VT-d, dunno. But that would simplify the stub development and maintenance significantly. BTW, uio's IRQ handling pattern is also related to this issue: A small, device-specific IRQ receiver is written as a kernel driver while the major driver code sits in user space and can handle the IRQ later - without disturbing other devices sharing IRQs with the uio device. Jan --------------enigDFB3F6720843C3FD69E61DEF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkjeBnYACgkQniDOoMHTA+luKwCePpJ8ytTY74KMpNllnwXsjKIL tZkAn3gNM2QJ4cvGApA2jElp/VWTa1Bi =hcHD -----END PGP SIGNATURE----- --------------enigDFB3F6720843C3FD69E61DEF--