WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] RE: [PATCH] [VT]long event-channel pending and mask arrays

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH] [VT]long event-channel pending and mask arrays
From: "Kamble, Nitin A" <nitin.a.kamble@xxxxxxxxx>
Date: Thu, 27 Oct 2005 16:33:06 -0700
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 27 Oct 2005 23:30:24 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcXbEpRhOzRBxJ55SlWQ5AQEGCVnywAOlO8A
Thread-topic: [PATCH] [VT]long event-channel pending and mask arrays
Keir,
 You are right. It can be changed to long but it is not necessary.

The issue in SMP dom0 for x86_64 got introduced before your SMP code
restructuring (merge smpboot.c) rev 7415. 

The rev 7412 has my fix for SMP dom0/domU. I have tested that fix here
which was working fine. That patch is pulled in the tree with many other
patches on the same day. With your 7402 patch (long masks) it is
breaking SMP dom0 differently. If I checkout the 7412 and then revert
the 7402 from it the SMP dom0 works fine. I can try reverting the 7402
changes from the latest tip to see what happens to SMP. Do you have any
better ideas?

>
>sync_const_test_bit does not need to change. Note it casts the bitmap
>pointer to 'int' which is 32-bit quantity even on x86/64. So we do want
>to divide the offset by 32, not BITS_PER_LONG.
>
>  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>