On Mon, Apr 10, 2006 at 02:08:18PM -0600, Alex Williamson wrote:
I'm having trouble with the legacy VGA memory descriptor section of
this patch.
I managed to get my system booting with the patch below (2-way, w/
1GB RAM). Networking works, yeah! The main changes here are that I
On Fri, 2006-04-21 at 15:04 +0900, Isaku Yamahata wrote:
Hi Alex.
What was the problem with the legacy VGA space?
Hi Isaku,
There are several problem as far as I can tell. First, what if the
system doesn't have legacy VGA? HP has several systems that might fall
into this category. We're
On Thu, 2006-04-13 at 23:53 -0600, Alex Williamson wrote:
I over estimated the abilities of 'hg serve', looks like it's only a
single threaded server not meant for much of a load. It's running, but
it only allows a single connection at a time, so if someone is doing an
'hg clone' it can be
On Wed, Apr 12, 2006 at 01:16:37PM +0800, Tian, Kevin wrote:
From: Isaku Yamahata
Sent: 2006年4月11日 17:23
It seems that the IOSAPIC area is not mapped to dom0.
Does the following patch make difference?
Could you send the all log?
Hi, Isaku,
If the 0xfae is the address of one
From: Isaku Yamahata [mailto:[EMAIL PROTECTED]
Sent: 2006年4月12日 14:10
Hi Kevin. Thanks for your testing.
The Tristan's log said that no page is assigned to the 0xfae area.
It doesn't seem that MMIO area covers the 0xfae area.
So Tristan's case is different from Alex's.
MDT table must be
On Wed, Apr 12, 2006 at 02:12:39PM +0800, Tian, Kevin wrote:
From: Isaku Yamahata [mailto:[EMAIL PROTECTED]
Sent: 2006年4月12日 14:10
Hi Kevin. Thanks for your testing.
The Tristan's log said that no page is assigned to the 0xfae area.
It doesn't seem that MMIO area covers the 0xfae
Le Mercredi 12 Avril 2006 07:16, Tian, Kevin a écrit :
From: Isaku Yamahata
Sent: 2006年4月11日 17:23
It seems that the IOSAPIC area is not mapped to dom0.
Does the following patch make difference?
Could you send the all log?
Hi, Isaku,
If the 0xfae is the address of one IOSAPIC
Le Mercredi 12 Avril 2006 08:12, Tian, Kevin a écrit :
From: Isaku Yamahata [mailto:[EMAIL PROTECTED]
[...]
That's an access to keyboard port possibly because now xen0/xenU
is compiled as one image with more drivers added. Maybe it's better
for us to map all 64M mmio area of domU to a
(Linux Kernel Dev)
Sent: Monday, April 10, 2006 2:08 PM
To: Isaku Yamahata
Cc: xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
On Mon, 2006-04-10 at 10:51 -0600, Alex Williamson wrote:
On Fri, 2006-04-07 at 13:16 +0900, Isaku Yamahata
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: 2006年4月12日 15:08
Le Mercredi 12 Avril 2006 08:12, Tian, Kevin a écrit :
From: Isaku Yamahata [mailto:[EMAIL PROTECTED]
[...]
That's an access to keyboard port possibly because now xen0/xenU
is compiled as one image with more drivers
Le Mercredi 12 Avril 2006 09:07, Tian, Kevin a écrit :
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: 2006年4月12日 15:08
Le Mercredi 12 Avril 2006 08:12, Tian, Kevin a écrit :
From: Isaku Yamahata [mailto:[EMAIL PROTECTED]
[...]
That's an access to keyboard port possibly
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: 2006年4月12日 15:20
Le Mercredi 12 Avril 2006 09:07, Tian, Kevin a écrit :
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: 2006年4月12日 15:08
Le Mercredi 12 Avril 2006 08:12, Tian, Kevin a écrit :
From: Isaku Yamahata [mailto:[EMAIL
Le Mercredi 12 Avril 2006 09:23, Tian, Kevin a écrit :
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
[...]
But this issues isn't specific to the P2M/VP patch.
I don't agree with this solution. I really prefer to have warnings
because it
means something got wrong. domU shouldn't
From: Tristan Gingold [mailto:[EMAIL PROTECTED]
Sent: 2006年4月12日 16:02
First, current code is taking mfn 0 as the result when mapping is not
found which is more problematic like write access as you mentioned
Second, mapping to a dummy page has similar effect, but no harm
for write
Writing
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alex
Williamson
Sent: 2006?4?12? 23:29
To: Tristan Gingold
Cc: Isaku Yamahata; xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
On Wed, 2006-04-12 at 09:01 +0100, Tristan Gingold
On Tue, Apr 11, 2006 at 09:29:18AM +0100, Tristan Gingold wrote:
Le Mardi 11 Avril 2006 03:52, Isaku Yamahata a écrit :
Thank you for testing.
On Mon, Apr 10, 2006 at 03:52:52PM +0100, Tristan Gingold wrote:
Le Vendredi 07 Avril 2006 06:16, Isaku Yamahata a écrit :
Hello.
I
Le Mardi 11 Avril 2006 11:23, Isaku Yamahata a écrit :
On Tue, Apr 11, 2006 at 09:29:18AM +0100, Tristan Gingold wrote:
Le Mardi 11 Avril 2006 03:52, Isaku Yamahata a écrit :
Thank you for testing.
On Mon, Apr 10, 2006 at 03:52:52PM +0100, Tristan Gingold wrote:
Le Vendredi 07
Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of Williamson, Alex (Linux Kernel Dev)
Sent: Monday, April 10, 2006 2:08 PM
To: Isaku Yamahata
Cc: xen-ia64-devel@lists.xensource.com
Subject: Re: [Xen-ia64-devel] [PATCH][RFC][TAKE4] the P2M/VP patches
On Mon, 2006
From: Isaku Yamahata
Sent: 2006年4月11日 17:23
It seems that the IOSAPIC area is not mapped to dom0.
Does the following patch make difference?
Could you send the all log?
Hi, Isaku,
If the 0xfae is the address of one IOSAPIC area, why
doesn't it get mapped at dom_fw_init? From your
Le Vendredi 07 Avril 2006 06:16, Isaku Yamahata a écrit :
Hello.
I attached the P2M/VP model patches take 4 for the change set
9492:2133fb78dba3cf6b6b88d1566fc5cc9de3039f43.
Please comments/request/review.
I am testing this on my FAME-C.
Currently it doesn't work: this is an infinite loop in
On Mon, 2006-04-10 at 13:55 +0900, Isaku Yamahata wrote:
I have the following ideas. I think B. or C. might be good.
What do you think of them?
A. record a huge region to somewhere (maybe struct arch_domain) and
add region check code to lookup_domian_mpa() (and its families)
for
On Mon, 2006-04-10 at 10:51 -0600, Alex Williamson wrote:
On Fri, 2006-04-07 at 13:16 +0900, Isaku Yamahata wrote:
9512:f5d0a531cb58_dom0_vp_model_xen_part.patch
I'm having trouble with the legacy VGA memory descriptor section of
this patch.
I managed to get my system booting
Thank you for testing.
On Mon, Apr 10, 2006 at 03:52:52PM +0100, Tristan Gingold wrote:
Le Vendredi 07 Avril 2006 06:16, Isaku Yamahata a écrit :
Hello.
I attached the P2M/VP model patches take 4 for the change set
9492:2133fb78dba3cf6b6b88d1566fc5cc9de3039f43.
Please
From: Alex Williamson
Sent: 2006年4月8日 1:07
Hi Isaku,
Great work! I'm happy to take on whatever patch load is necessary
to
help faciliate this effort. I'll get the header file patches into the
tree. It will be important for all of us to help test and review these
patches over the next few
Hi Alex.
I understand what's going on.
(I wrote the last mail in hurry. so I didn't look the log so closely.
sorry for that)
(XEN) mem40: type=11, attr=0x1, range=[0x0800-0x1000)
(8388608MB)
Plase note that type = 11 = EFI_MEMORY_MAPPED_IO
About 8TB (~= 8388608MB /
On Mon, 2006-04-10 at 11:46 +0900, Isaku Yamahata wrote:
(XEN) mem40: type=11, attr=0x1,
range=[0x0800-0x1000) (8388608MB)
Plase note that type = 11 = EFI_MEMORY_MAPPED_IO
About 8TB (~= 8388608MB / 1024) is required to map this range
to dom0 for the P2M
On Sun, Apr 09, 2006 at 09:43:07PM -0600, Alex Williamson wrote:
Maybe some special code for handling such a huge range is needed.
Yes, for the short term we may be able to ignore this range, but we
need a solution fairly soon as it's possible firmware or dom0 might
choose to map cards
On Sat, 2006-04-08 at 13:41 +0900, Isaku Yamahata wrote:
Could you try again with the following work around patch?
This patch may break something, but this patch may help
to track down this issue.
Hi Yamata,
I tried alloc_domheap_pages(NULL, 0, 0) in pgtable_quicklist_alloc().
I don't
From: Isaku Yamahata
Sent: 2006年4月7日 12:16
* summary
With these patches, dom0, domU boot and vnif, balloon works.
Great progress.
9504:c50a58f28451_fix_grant_entry_t_frame.patch
change the type of grant_entry::frame from uint32_t to
unsigned long.
In theory IA64 supports 50 bits
From: Isaku Yamahata [mailto:[EMAIL PROTECTED]
Sent: 2006年4月7日 15:48
I'll post a quick hack patch for xenLinux/x86 (but only compile-test)
when I post this patch.
A new conversion function needs to be introduced.
unsigned long pfn_to_mfn_for_dma(unsigned long pfn)
{
if
On Fri, Apr 07, 2006 at 03:57:30PM +0800, Tian, Kevin wrote:
Does this patch only save one hypercall overhead? We can always
tell guest the auto_translated bit is true when guest hypercalls to
query feature bits into xen_feature array.
No.
I agree that we can go without this patch by
Hi,
a side question:
[...]
- 9536:357ffc54d5ca_make_vhpt_64kb.patch
Without this patch linux software lock up detection is triggered.
This is a temporal work around.
In fact it is very easy to trigger the software lock up: pause and unpause a
domain. Is software lockup enabled on
On Fri, 2006-04-07 at 13:16 +0900, Isaku Yamahata wrote:
As the first step I propose merging the patches which import header files.
It is trivial to import those header files.
In fact this might increase the repository maintainer's (Alex) task.
But those header files are quite stable, so I
Hi Alex.
On Fri, Apr 07, 2006 at 11:06:53AM -0600, Alex Williamson wrote:
Great work! I'm happy to take on whatever patch load is necessary to
help faciliate this effort. I'll get the header file patches into the
tree. It will be important for all of us to help test and review these
34 matches
Mail list logo
