[Xen-ia64-devel][PATCH] workaround for itr_d
Workaround for itr_d This is a bad workaround In linux, region 7 use 16M page size, and it is identity mapping, While VHPT page size is 16K in XEN, if purge VHPT while guest insert 16M TR, It will iterate purge VHPT 1024 times, which makes XEN/IFF very slow. XEN doesn't purge VHPT Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, Anthony workaround_for_itr_d.patch Description: workaround_for_itr_d.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH] workaround for itr_d
+if(ps != 24) Hi Anthony. _PAGE_SIZE_16M should be used instead of a magic number, 24. On Wed, Sep 20, 2006 at 05:29:55PM +0800, Xu, Anthony wrote: Workaround for itr_d This is a bad workaround In linux, region 7 use 16M page size, and it is identity mapping, While VHPT page size is 16K in XEN, if purge VHPT while guest insert 16M TR, It will iterate purge VHPT 1024 times, which makes XEN/IFF very slow. XEN doesn't purge VHPT Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, Anthony ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] pickled code
Hi,
I found another interesting issue in the code - the way the 'pickle'
functions work just cannot be right. There is no way one should ever
try and truncate the output of __pa() to u32 or expect to be able to
run __va() on a u32 and obtain any level of usable output.
I have to admit I have zero clue what the pickle code is trying to
achieve, but I am at least fairly confident that something needs to
be done in this space :(
Cheers,
Jes
Truncating __va() and __pa() output to u32 is simply not going to work.
Some platforms don't even have any physical memory within the 4GB window.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 3e4fa8b5b245 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cTue Sep 12 11:43:22 2006 -0600
+++ b/xen/arch/ia64/xen/mm.cWed Sep 20 15:47:09 2006 +0200
@@ -213,7 +213,7 @@ static void
static void
try_to_clear_PGC_allocate(struct domain* d, struct page_info* page)
{
-u32 _d, _nd;
+u64 _d, _nd;
u64 x, nx, y;
_d = pickle_domptr(d);
@@ -1329,7 +1349,7 @@ steal_page(struct domain *d, struct page
#if 0 /* if big endian */
# error implement big endian version of steal_page()
#endif
-u32 _d, _nd;
+u64 _d, _nd;
u64 x, nx, y;
if (page_get_owner(page) != d) {
diff -r 3e4fa8b5b245 xen/include/asm-ia64/mm.h
--- a/xen/include/asm-ia64/mm.h Tue Sep 12 11:43:22 2006 -0600
+++ b/xen/include/asm-ia64/mm.h Wed Sep 20 14:12:43 2006 +0200
@@ -53,7 +53,7 @@ struct page_info
/* Page is in use: ((count_info PGC_count_mask) != 0). */
struct {
/* Owner of this page (NULL if page is anonymous). */
-u32 _domain; /* pickled format */
+u64 _domain; /* pickled format */
/* Type reference count and various PGT_xxx flags and fields. */
unsigned long type_info;
} __attribute__ ((packed)) inuse;
@@ -125,10 +125,10 @@ struct page_info
#define IS_XEN_HEAP_FRAME(_pfn) ((page_to_maddr(_pfn) xenheap_phys_end) \
(page_to_maddr(_pfn) = xen_pstart))
-static inline struct domain *unpickle_domptr(u32 _d)
+static inline struct domain *unpickle_domptr(u64 _d)
{ return (_d == 0) ? NULL : __va(_d); }
static inline u32 pickle_domptr(struct domain *_d)
-{ return (_d == NULL) ? 0 : (u32)__pa(_d); }
+{ return (_d == NULL) ? 0 : (u64)__pa(_d); }
#define page_get_owner(_p) (unpickle_domptr((_p)-u.inuse._domain))
#define page_set_owner(_p, _d) ((_p)-u.inuse._domain = pickle_domptr(_d))
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [patch] PAGE_ALIGN mpt_table
Hi, This seems like a reasonable thing to do to me, and also means Xen doesn't MCA on the first attempt to access the mpt_table here. Cheers, Jes Page-align mpt_table - without this patch, Xen MCA's on the first attempt to try and touch the mpt_table as it was aligned at some crazy address. Signed-off-by: Jes Sorensen [EMAIL PROTECTED] diff -r 3e4fa8b5b245 xen/arch/ia64/xen/xenmem.c --- a/xen/arch/ia64/xen/xenmem.cTue Sep 12 11:43:22 2006 -0600 +++ b/xen/arch/ia64/xen/xenmem.cWed Sep 20 17:14:01 2006 +0200 @@ -184,7 +184,8 @@ void init_virtual_frametable(void) /* Allocate virtual mpt_table */ table_size = 0; - mpt_table = (unsigned long *)VIRT_FRAME_TABLE_END - max_page; + mpt_table = (unsigned long *) + PAGE_ALIGN(VIRT_FRAME_TABLE_END - max_page); efi_memmap_walk(create_mpttable_page_table, NULL); printk(virtual machine to physical table: %p size: %lukB\n ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][PATCH] workaround for itr_d
-Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年9月20日 17:40 To: Xu, Anthony Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel][PATCH] workaround for itr_d +if(ps != 24) Hi Anthony. _PAGE_SIZE_16M should be used instead of a magic number, 24. On Wed, Sep 20, 2006 at 05:29:55PM +0800, Xu, Anthony wrote: Workaround for itr_d This is a bad workaround In linux, region 7 use 16M page size, and it is identity mapping, While VHPT page size is 16K in XEN, if purge VHPT while guest insert 16M TR, It will iterate purge VHPT 1024 times, which makes XEN/IFF very slow. XEN doesn't purge VHPT Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, Anthony ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel][PATCH] workaround for itr_d
Hi Yamahata Thanks for your comments, This is updated one. Thanks, Anthony -Original Message- From: Isaku Yamahata [mailto:[EMAIL PROTECTED] Sent: 2006年9月20日 17:40 To: Xu, Anthony Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel][PATCH] workaround for itr_d +if(ps != 24) Hi Anthony. _PAGE_SIZE_16M should be used instead of a magic number, 24. On Wed, Sep 20, 2006 at 05:29:55PM +0800, Xu, Anthony wrote: Workaround for itr_d This is a bad workaround In linux, region 7 use 16M page size, and it is identity mapping, While VHPT page size is 16K in XEN, if purge VHPT while guest insert 16M TR, It will iterate purge VHPT 1024 times, which makes XEN/IFF very slow. XEN doesn't purge VHPT Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, Anthony ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel -- yamahata workaround_for_itr_d2.patch Description: workaround_for_itr_d2.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] pickled code
Hi Jes, When I created a domU, Xen does the panic with your patch. Because _domain of page_info structure was changed to u64, type_info of page_info structure is not 8 bytes alignment. Best regards, Kan Kernel command line: root=/dev/hda1 ro nomca nosmp xencons=tty0 console=tty0 3 PID hash table entries: 2048 (order: 11, 65536 bytes) lookup_domain_mpa: d 0xf7de0080 id 1 current 0xf7db8000 id 0 (XEN) lookup_domain_mpa: bad mpa 0xc019064 (= 0x2000) (XEN) Warning: UC to WB for mpaddr=c019064 008226018, isr=0x0a06 (XEN) Unaligned Reference. (XEN) d 0xf4290080 domid 0 (XEN) vcpu 0xf4268000 vcpu 0 (XEN) (XEN) CPU 0 (XEN) psr : 121008226018 ifs : 8994 ip : [f4067191] (XEN) ip is at get_page_type+0xf1/0x300 (XEN) unat: pfs : 0ea3 rsc : 0003 (XEN) rnat: bsps: pr : 0002aa69 (XEN) ldrs: ccv : fpsr: 0009804c0270033f (XEN) csd : ssd : (XEN) b0 : f4029e30 b6 : f40290a0 b7 : a00100068510 (XEN) f6 : 08000 f7 : 1003e6db6db6db6db6db7 (XEN) f8 : 1003e0002085a f9 : 1003e (XEN) f10 : 100079cd9967f8c00 f11 : 1003e0139 (XEN) r1 : f43168d0 r2 : e0001fb5fd90 r3 : e0001fb5fd91 (XEN) r8 : 0001 r9 : r10 : (XEN) r11 : 09e9 r12 : f426f920 r13 : f4268000 (XEN) r14 : e001 r15 : 07de0080 r16 : (XEN) r17 : 07de00808002 r18 : 07de0080 r19 : 1fff (XEN) r20 : f426f928 r21 : 8000 r22 : (XEN) r23 : r24 : f426fe20 r25 : f426fe28 (XEN) r26 : r27 : r28 : (XEN) r29 : 0001 r30 : r31 : f7de3828 (XEN) (XEN) Call Trace: (XEN) [f4098140] show_stack+0x80/0xa0 (XEN) sp=f426f550 bsp=f42690c8 (XEN) [f406c300] ia64_fault+0x280/0x670 (XEN) sp=f426f720 bsp=f4269090 (XEN) [f4095100] ia64_leave_kernel+0x0/0x310 (XEN) sp=f426f720 bsp=f4269090 (XEN) [f4067190] get_page_type+0xf0/0x300 (XEN) sp=f426f920 bsp=f4268fe8 (XEN) [f4029e30] do_grant_table_op+0x1090/0x18d0 (XEN) sp=f426f920 bsp=f4268f00 (XEN) [f405d0e0] ia64_hypercall+0x4f0/0xe00 (XEN) sp=f426f940 bsp=f4268ea0 (XEN) [f406c840] ia64_handle_break+0x150/0x2e0 (XEN) sp=f426fdf0 bsp=f4268e68 (XEN) [f4095100] ia64_leave_kernel+0x0/0x310 (XEN) sp=f426fe00 bsp=f4268e68 (XEN) (XEN) (XEN) Panic on CPU 0: (XEN) Fault in Xen. (XEN) (XEN) (XEN) Reboot in five seconds... Hi, I found another interesting issue in the code - the way the 'pickle' functions work just cannot be right. There is no way one should ever try and truncate the output of __pa() to u32 or expect to be able to run __va() on a u32 and obtain any level of usable output. I have to admit I have zero clue what the pickle code is trying to achieve, but I am at least fairly confident that something needs to be done in this space :( Cheers, Jes ---text/plain--- ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result
Hi, Yongkang I think this issue is configuration mistakes. Can you try the following configuration? I cannot try it because I meet another issue... 1. /etc/modprobe.conf for initrd of domU The following configuration would solve the issue of booting domU. [EMAIL PROTECTED] xen]# cat /etc/modprobe.conf #alias eth0 e1000 #alias scsi_hostadapter mptbase #alias scsi_hostadapter1 mptspi alias eth0 xennet this alias scsi_hostadapter xenblk and this 2. domU.conf The following configuration would solve the issue of probing ide disk. kernel = vmlinuz-2.6.17-1.2630.fc6xen ramdisk = initrd-2.6.17-1.2630.fc6xenU.img memory = 512 name = domU vif = [ '' ] disk = [ 'file:/xen/image/fc6.root.img,hda1,w' ] root = /dev/hda1 ro extra = 3 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe this Best Regards, Akio Takebe Hi, I have reported 2 bugs to redhat bugzilla: [Bug 207227] New: Xen0 reboot command can not reboot Tiger4 machine. [Bug 207241] New: XenU domain can not be created successfully. New xenU created failure serial log has been pasted to the bug. I also notice FC6-test3 Xen0 operation is a little slower, compared with RHEL4u3. I assign 2 vcpus to Xen0. When I destroy domains or do some heavy IO operations, Xen0 operations will be blocked for a while. I didn't track this to bugzilla. There are also a lot of unaligned accessing from some applications. They should be common FC6-test3 issues. Sometime Xen0 monitor will print Bug: soft lockup detected on CPU#0(or #1) Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of You, Yongkang Sent: 2006ト\xF3ヤツ20ネユ 10:07 To: Yang, Fred; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Hi Fred Yoshi, The former XenU creating failure issue seemed to be the config issue. Now I can create XenU. But XenU booting process met an old bug. It will cost a long time to check hard disk IRQ response from hda to hdh. After that, xenU met the problem of mounting root partition to start services, and then XenU booting failed (Kill init). I am not sure if it is because initrd issue. I will continue to check it. Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yang, Fred Sent: 2006ト\xF3ヤツ20ネユ 8:26 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Here it comes! -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 4:23 PM To: Yang, Fred; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Fred, Yongkang, Other issues: 1) Xen0 operation is a little slower than RHEL4u3. 2) XenU creating failure, please see attachment for the serial output. I can't find the attachment. Could you repost the serial log? Thanks, Yoshi Oguchi Yang, Fred [EMAIL PROTECTED] wrote」コ Following is the quick Xen test result with FC6 Test3. We will file BZ for the issues tonight; the early data is to get community to fix Xen issues ASAP Thanks, -Fred I have followed Redhat instructions (FC6-test3 can not be installed from CDs) to install FC6-Test3 and do some testing. Both Xen0 and VTI can all boot up, but XenU couldn't be created successfully. Detailed Items: 1. Using yum to upgrade FC6 Test2 to FC6 Test3[almost Pass] need manually reinstall kernel-xen rpm package. 2. Boot Native Linux of FC6 Test3 [Pass] 3. Boot Xen of FC6 Test3 [Pass] 4. xend and xm commands are working.[Pass] 5. XenU Domain creating failed. [__FAIL__] 6. Missing VTI guest firmware (/usr/lib/xen/boot/guest_firmware.bin) [__FAIL__ (expected)] 7. After manually copy VTI guest firmware, creating VTI domain [Pass] 8.VTI domain with network supported [Pass] 9.2 VTI domains coexisting testing [Pass] 10. Linux Kernel build in VTI domain [Pass] 11. LTP testing in VTI domain [Pass] 12. SMP VTI domain [Pass] 13. SMP Xen0 [Pass] 14. 1 VTI Windows 2k3 [Pass] a little slower. 15. 1 VTI Linux + 1 VTI Windows[__FAIL__ VTI Windows blue screen] 16. Reboot machine failed with Xen FC6-test3. [__FAIL__] Other issues: 1) Xen0 operation is a little slower than RHEL4u3. 2) XenU creating failure, please see attachment for the serial output. Best Regards, Yongkang (Kangkang) モタソオ ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel ___ Xen-ia64-devel mailing list
Re: [Xen-ia64-devel] pickled code
Hi Jes.
It tries to keep struct page_info compact layout by avoiding
padding before _domain member.
Please notice u32 count_info member in front of _domain.
struct domain is allocated from xen heap,
i.e. the range [PAGE_OFFSET, PAGE_OFFSET + 64MB).
It means that struct domain* can be expressed as
PAGE_OFFSET + 32bit offset(=machine phsyiacal address).
pickle PAGE_OFFSET + 32bit offset = 32 bit offset
i.e. discarding most significant 32bit.
It can be don by casting u64 to u32 because
Xen assumes little endian.
unpickle32bit offset(=machine phsyical address)
= PAGE_OFFSET + 32 bit offset
i.e. __va()
On Wed, Sep 20, 2006 at 04:21:56PM +0200, Jes Sorensen wrote:
Hi,
I found another interesting issue in the code - the way the 'pickle'
functions work just cannot be right. There is no way one should ever
try and truncate the output of __pa() to u32 or expect to be able to
run __va() on a u32 and obtain any level of usable output.
I have to admit I have zero clue what the pickle code is trying to
achieve, but I am at least fairly confident that something needs to
be done in this space :(
Cheers,
Jes
Truncating __va() and __pa() output to u32 is simply not going to work.
Some platforms don't even have any physical memory within the 4GB window.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 3e4fa8b5b245 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c Tue Sep 12 11:43:22 2006 -0600
+++ b/xen/arch/ia64/xen/mm.c Wed Sep 20 15:47:09 2006 +0200
@@ -213,7 +213,7 @@ static void
static void
try_to_clear_PGC_allocate(struct domain* d, struct page_info* page)
{
-u32 _d, _nd;
+u64 _d, _nd;
u64 x, nx, y;
_d = pickle_domptr(d);
@@ -1329,7 +1349,7 @@ steal_page(struct domain *d, struct page
#if 0 /* if big endian */
# error implement big endian version of steal_page()
#endif
-u32 _d, _nd;
+u64 _d, _nd;
u64 x, nx, y;
if (page_get_owner(page) != d) {
diff -r 3e4fa8b5b245 xen/include/asm-ia64/mm.h
--- a/xen/include/asm-ia64/mm.h Tue Sep 12 11:43:22 2006 -0600
+++ b/xen/include/asm-ia64/mm.h Wed Sep 20 14:12:43 2006 +0200
@@ -53,7 +53,7 @@ struct page_info
/* Page is in use: ((count_info PGC_count_mask) != 0). */
struct {
/* Owner of this page (NULL if page is anonymous). */
-u32 _domain; /* pickled format */
+u64 _domain; /* pickled format */
/* Type reference count and various PGT_xxx flags and fields. */
unsigned long type_info;
} __attribute__ ((packed)) inuse;
@@ -125,10 +125,10 @@ struct page_info
#define IS_XEN_HEAP_FRAME(_pfn) ((page_to_maddr(_pfn) xenheap_phys_end) \
(page_to_maddr(_pfn) = xen_pstart))
-static inline struct domain *unpickle_domptr(u32 _d)
+static inline struct domain *unpickle_domptr(u64 _d)
{ return (_d == 0) ? NULL : __va(_d); }
static inline u32 pickle_domptr(struct domain *_d)
-{ return (_d == NULL) ? 0 : (u32)__pa(_d); }
+{ return (_d == NULL) ? 0 : (u64)__pa(_d); }
#define page_get_owner(_p) (unpickle_domptr((_p)-u.inuse._domain))
#define page_set_owner(_p, _d) ((_p)-u.inuse._domain =
pickle_domptr(_d))
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] pickled code
I forgot to memtion an important thing.
Xen needs to change both reference count(count member) and
its page owner(_domain member) atomically.
Some codes depends on the fact that count and _domain are packed in 64bit.
e.g. steal_page().
On Thu, Sep 21, 2006 at 10:34:04AM +0900, Isaku Yamahata wrote:
Hi Jes.
It tries to keep struct page_info compact layout by avoiding
padding before _domain member.
Please notice u32 count_info member in front of _domain.
struct domain is allocated from xen heap,
i.e. the range [PAGE_OFFSET, PAGE_OFFSET + 64MB).
It means that struct domain* can be expressed as
PAGE_OFFSET + 32bit offset(=machine phsyiacal address).
pickle PAGE_OFFSET + 32bit offset = 32 bit offset
i.e. discarding most significant 32bit.
It can be don by casting u64 to u32 because
Xen assumes little endian.
unpickle32bit offset(=machine phsyical address)
= PAGE_OFFSET + 32 bit offset
i.e. __va()
On Wed, Sep 20, 2006 at 04:21:56PM +0200, Jes Sorensen wrote:
Hi,
I found another interesting issue in the code - the way the 'pickle'
functions work just cannot be right. There is no way one should ever
try and truncate the output of __pa() to u32 or expect to be able to
run __va() on a u32 and obtain any level of usable output.
I have to admit I have zero clue what the pickle code is trying to
achieve, but I am at least fairly confident that something needs to
be done in this space :(
Cheers,
Jes
Truncating __va() and __pa() output to u32 is simply not going to work.
Some platforms don't even have any physical memory within the 4GB window.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
diff -r 3e4fa8b5b245 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cTue Sep 12 11:43:22 2006 -0600
+++ b/xen/arch/ia64/xen/mm.cWed Sep 20 15:47:09 2006 +0200
@@ -213,7 +213,7 @@ static void
static void
try_to_clear_PGC_allocate(struct domain* d, struct page_info* page)
{
-u32 _d, _nd;
+u64 _d, _nd;
u64 x, nx, y;
_d = pickle_domptr(d);
@@ -1329,7 +1349,7 @@ steal_page(struct domain *d, struct page
#if 0 /* if big endian */
# error implement big endian version of steal_page()
#endif
-u32 _d, _nd;
+u64 _d, _nd;
u64 x, nx, y;
if (page_get_owner(page) != d) {
diff -r 3e4fa8b5b245 xen/include/asm-ia64/mm.h
--- a/xen/include/asm-ia64/mm.h Tue Sep 12 11:43:22 2006 -0600
+++ b/xen/include/asm-ia64/mm.h Wed Sep 20 14:12:43 2006 +0200
@@ -53,7 +53,7 @@ struct page_info
/* Page is in use: ((count_info PGC_count_mask) != 0). */
struct {
/* Owner of this page (NULL if page is anonymous). */
-u32 _domain; /* pickled format */
+u64 _domain; /* pickled format */
/* Type reference count and various PGT_xxx flags and fields.
*/
unsigned long type_info;
} __attribute__ ((packed)) inuse;
@@ -125,10 +125,10 @@ struct page_info
#define IS_XEN_HEAP_FRAME(_pfn) ((page_to_maddr(_pfn) xenheap_phys_end) \
(page_to_maddr(_pfn) = xen_pstart))
-static inline struct domain *unpickle_domptr(u32 _d)
+static inline struct domain *unpickle_domptr(u64 _d)
{ return (_d == 0) ? NULL : __va(_d); }
static inline u32 pickle_domptr(struct domain *_d)
-{ return (_d == NULL) ? 0 : (u32)__pa(_d); }
+{ return (_d == NULL) ? 0 : (u64)__pa(_d); }
#define page_get_owner(_p) (unpickle_domptr((_p)-u.inuse._domain))
#define page_set_owner(_p, _d) ((_p)-u.inuse._domain =
pickle_domptr(_d))
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel][PATCH] Fix a bug related to vcpu migration
When destroying domain, only LPs, this domain is running on, do local TLB purge, Other LPs may still have TLBs belonging to this domain, When another domain is created, this may have the same region ID range with old domain, and may conflict with old TLB belonging to old domain. I did observe this scenario, after destroyingcreating domain several times, Domain crashing happens. This patch is intended to resolve this issue. Just before launching a VCPU on a LP, Xen purges local TLB on this LP. Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, Anthony vcpu_migration_fix.patch Description: vcpu_migration_fix.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH] Fix a bug related to vcpu migration
On Thu, Sep 21, 2006 at 09:49:01AM +0800, Xu, Anthony wrote: When destroying domain, only LPs, this domain is running on, do local TLB purge, Other LPs may still have TLBs belonging to this domain, When another domain is created, this may have the same region ID range with old domain, and may conflict with old TLB belonging to old domain. I did observe this scenario, after destroyingcreating domain several times, Domain crashing happens. This patch is intended to resolve this issue. Just before launching a VCPU on a LP, Xen purges local TLB on this LP. Hi Anthony. domain_flush_tlb_vhpt() called by arch_domain_destroy() addresses this scneario. I don't think the patch resolves the domain crash issue because it flushes TLB before region ID range is reused. Have you observed domain crash with the patch? If the domain crash disappeared with your patch, we might have different issues, I guess. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result
Hi, Yongkang I have a small mistake. Please try the following configuration. kernel = vmlinuz-2.6.17-1.2630.fc6xen ramdisk = initrd-2.6.17-1.2630.fc6xenU.img memory = 512 name = domU vif = [ '' ] disk = [ 'file:/xen/image/fc6.root.img,sda1,w' ] this root = /dev/sda1 ro this extra = 3 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe --- -this Best Regards, Akio Takebe Hi, Yongkang I think this issue is configuration mistakes. Can you try the following configuration? I cannot try it because I meet another issue... 1. /etc/modprobe.conf for initrd of domU The following configuration would solve the issue of booting domU. [EMAIL PROTECTED] xen]# cat /etc/modprobe.conf #alias eth0 e1000 #alias scsi_hostadapter mptbase #alias scsi_hostadapter1 mptspi alias eth0 xennet this alias scsi_hostadapter xenblk and this 2. domU.conf The following configuration would solve the issue of probing ide disk. kernel = vmlinuz-2.6.17-1.2630.fc6xen ramdisk = initrd-2.6.17-1.2630.fc6xenU.img memory = 512 name = domU vif = [ '' ] disk = [ 'file:/xen/image/fc6.root.img,hda1,w' ] root = /dev/hda1 ro extra = 3 ide0=noprobe ide1=noprobe ide2=noprobe ide3=noprobe this Best Regards, Akio Takebe Hi, I have reported 2 bugs to redhat bugzilla: [Bug 207227] New: Xen0 reboot command can not reboot Tiger4 machine. [Bug 207241] New: XenU domain can not be created successfully. New xenU created failure serial log has been pasted to the bug. I also notice FC6-test3 Xen0 operation is a little slower, compared with RHEL4u3. I assign 2 vcpus to Xen0. When I destroy domains or do some heavy IO operations, Xen0 operations will be blocked for a while. I didn't track this to bugzilla. There are also a lot of unaligned accessing from some applications. They should be common FC6-test3 issues. Sometime Xen0 monitor will print Bug: soft lockup detected on CPU#0(or #1) Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of You, Yongkang Sent: 2006トsヤツ20ネユ 10:07 To: Yang, Fred; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Hi Fred Yoshi, The former XenU creating failure issue seemed to be the config issue. Now I can create XenU. But XenU booting process met an old bug. It will cost a long time to check hard disk IRQ response from hda to hdh. After that, xenU met the problem of mounting root partition to start services, and then XenU booting failed (Kill init). I am not sure if it is because initrd issue. I will continue to check it. Best Regards, Yongkang (Kangkang) モタソオ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yang, Fred Sent: 2006トsヤツ20ネユ 8:26 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: RE: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Here it comes! -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 19, 2006 4:23 PM To: Yang, Fred; [EMAIL PROTECTED] Cc: xen-ia64-devel@lists.xensource.com Subject: Re: [Xen-ia64-devel] [Fedora-ia64-list] FC6 Test3 Xen test result Fred, Yongkang, Other issues: 1) Xen0 operation is a little slower than RHEL4u3. 2) XenU creating failure, please see attachment for the serial output. I can't find the attachment. Could you repost the serial log? Thanks, Yoshi Oguchi Yang, Fred [EMAIL PROTECTED] wrote」コ Following is the quick Xen test result with FC6 Test3. We will file BZ for the issues tonight; the early data is to get community to fix Xen issues ASAP Thanks, -Fred I have followed Redhat instructions (FC6-test3 can not be installed from CDs) to install FC6-Test3 and do some testing. Both Xen0 and VTI can all boot up, but XenU couldn't be created successfully. Detailed Items: 1. Using yum to upgrade FC6 Test2 to FC6 Test3[almost Pass] need manually reinstall kernel-xen rpm package. 2. Boot Native Linux of FC6 Test3 [Pass] 3. Boot Xen of FC6 Test3 [Pass] 4. xend and xm commands are working.[Pass] 5. XenU Domain creating failed. [__FAIL__] 6. Missing VTI guest firmware (/usr/lib/xen/boot/guest_firmware.bin) [__FAIL__ (expected)] 7. After manually copy VTI guest firmware, creating VTI domain [Pass] 8.VTI domain with network supported [Pass] 9.2 VTI domains coexisting testing [Pass] 10. Linux Kernel build in VTI domain [Pass] 11. LTP testing in VTI domain [Pass] 12. SMP VTI domain [Pass] 13. SMP Xen0 [Pass] 14. 1 VTI Windows 2k3 [Pass] a little slower. 15. 1 VTI Linux + 1 VTI Windows[__FAIL__ VTI Windows blue screen] 16. Reboot machine failed with Xen FC6-test3. [__FAIL__] Other issues: 1) Xen0
RE: [Xen-ia64-devel][PATCH] Fix a bug related to vcpu migration
From: Isaku Yamahata [mailto:[EMAIL PROTECTED]
Sent: 2006年9月21日 10:14
To: Xu, Anthony
Cc: xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-ia64-devel][PATCH] Fix a bug related to vcpu migration
On Thu, Sep 21, 2006 at 09:49:01AM +0800, Xu, Anthony wrote:
When destroying domain, only LPs, this domain is running on, do local
TLB purge,
Other LPs may still have TLBs belonging to this domain,
When another domain is created, this may have the same region ID range
with old domain,
and may conflict with old TLB belonging to old domain.
I did observe this scenario, after destroyingcreating domain several
times,
Domain crashing happens.
This patch is intended to resolve this issue.
Just before launching a VCPU on a LP, Xen purges local TLB on this LP.
Hi Anthony.
domain_flush_tlb_vhpt() called by arch_domain_destroy()
addresses this scneario.
I don't think the patch resolves the domain crash issue because it
flushes TLB before region ID range is reused.
Yes, you are right, domain_flush_tlb_vhpt() can addresses this scenario.
One comment about flush_tlb_vhpt_all,
static void flush_tlb_vhpt_all (struct domain *d)
{
/* First VHPT. */
if d is not VMX domain
vhpt_flush ();
/* Then mTLB. */
local_flush_tlb_all ();
}
Have you observed domain crash with the patch?
If the domain crash disappeared with your patch,
we might have different issues, I guess.
Before this patch, both dom0 and VTI domain hang after several createdestroy.
After this patch, both dom0 and VTI domain are alive after more than one
hundred createdestroy.
Seems this issue is related with TLB, I'll continue to debug this.
Thanks,
Anthony
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH] Fix a bug related to vcpu migration
On Thu, Sep 21, 2006 at 11:22:27AM +0800, Xu, Anthony wrote:
domain_flush_tlb_vhpt() called by arch_domain_destroy()
addresses this scneario.
I don't think the patch resolves the domain crash issue because it
flushes TLB before region ID range is reused.
Yes, you are right, domain_flush_tlb_vhpt() can addresses this scenario.
One comment about flush_tlb_vhpt_all,
static void flush_tlb_vhpt_all (struct domain *d)
{
/* First VHPT. */
if d is not VMX domain
vhpt_flush ();
/* Then mTLB. */
local_flush_tlb_all ();
}
Now I see your point.
Then arch_domain_destroy() or domain_flush_tlb_vhpt() should be fixed.
make it be aware of domVTI.
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel][PATCH] Fix a bug about set_rse_reg
When setting rse register, XEN needs to modify banking store memory. This operation can't be interrupted, otherwise contents of stack registers may be destroyed. BTW, after this patch, crashme can pass on SMP VTI-domain. Signed-off-by: Anthony Xu [EMAIL PROTECTED] Thanks, Anthony set_rse_reg_fix.patch Description: set_rse_reg_fix.patch ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
