From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: RE: use of struct hvm_mirq_dpci_mapping.gmsi vs. HVM_IRQ_DPCI_*_MSI flags Date: Fri, 29 Apr 2011 08:05:01 +0100 Message-ID: <4DBA7F3D020000780003ED4A@vpn.id2.novell.com> References: <4D94A88C0200007800039637@vpn.id2.novell.com> <4DB6A2EE020000780003E1DC@vpn.id2.novell.com> <987664A83D2D224EAE907B061CE93D5301C50FD4BF@orsmsx505.amr.corp.intel.com> <4DB7D72A020000780003E4C4@vpn.id2.novell.com> <987664A83D2D224EAE907B061CE93D5301C524FBCC@orsmsx505.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <987664A83D2D224EAE907B061CE93D5301C524FBCC@orsmsx505.amr.corp.intel.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Allen M Kay Cc: Haitao Shan , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org >>> On 28.04.11 at 22:27, "Kay, Allen M" wrote: > 2) HVM_IRQ_DPCI_GUEST_MSI and HVM_IRQ_DPCI_MACH_MSI usage: These are = for=20 > handle cases various combination of host and guest interrupt types -=20 > host_msi/guest_msi, host_intx/guest_intx, host_msi/guest_intx. The last = one=20 > requires translation flag. It is for supporting non MSI capable guests. = The=20 > engineer originally worked on this is no longer working on this project. = You=20 > are welcome to clean up if necessary. However, testing various = host/guest=20 > interrupt combinations and make sure everything still works is quite a = bit of=20 > work. The problem is that from what I can tell the current use is inconsistent, and this inconsistency is causing problems with the data layout change. Iirc there's no problem as long as there's not going to be a union for overlaying the PCI/gMSI fields, so I'm going to leave off that part for the first step. As to testing - I'll have to rely on someone at your end doing the full testing of these changes anyway; I simply don't have the hardware (and time) to do all that. > 3) I believe the locking mechanism was originally implemented by=20 > Espen@netrome(?) so we are not sure about why the unlock is needed = between=20 > two iterations. We have also encountered several which we would like = to=20 > clean up. However, we left it as low priority task as the locking = mechanisms=20 > are quite complex and the amount of testing required after the cleanup = is a=20 > quite a bit of work. Then we'll have to see how it goes with the change - see above for the testing part. Jan