On 30/1/08 08:48, Akio Takebe [EMAIL PROTECTED] wrote:
This doesn't need to be fixed on x86 -- the int3 handler will return
silently if the debugger is not configured. It would be nice if the ia64
handler would do the same. If that is not possible then change only ia64
code and if you need to
A new releaase candidate is tagged in
http://xenbits.xensource.com/xen-3.1-testing.hg. Assuming no problems are
revealed by testing, I'd like to make this the proper 3.1.3 release asap.
Thanks,
Keir
___
Xen-ppc-devel mailing list
No changes are allowed to the tools interfaces within a stable release
series. It'll be in 3.2.0 in a few weeks time.
-- Keir
On 29/10/07 15:37, beth kon [EMAIL PROTECTED] wrote:
Hi. Wondering if this patch has been reviewed and could be considered
for inclusion in 3.2. Sorry about the late
Can you please provide a patch to apply to xen-3.1-testing.pq.hg? The
patches you add to the queue should have the same style of changeset comment
as the existing ones -- 'hg export' format plus the two xen-unstable
changeset references immediately after the signed-off-by line(s).
I've cc'ed Ben
Hi,
A provisional patchqueue for Xen 3.1.1 is available at
http://xenbits.xensource.com/xen-3.1-testing.pq.hg. This pq partners with
http://xenbits.xensource.com/xen-3.1-testing.hg.
Please kick this pq around and check whether the patches you want to see in
3.1.1 are included.
-- Keir
On 10/9/07 13:03, Ben Guthro [EMAIL PROTECTED] wrote:
15185-1f8fb764f843
http://xenbits.xensource.com/xen-unstable.hg?rev/1f8fb764f843
I'm inclined not to backport this one.
15806-577313e3c0a6 (not exactly crucial, but would be nice)
On 14/8/07 10:50, Isaku Yamahata [EMAIL PROTECTED] wrote:
This take 3 patch series is for xencomm consolidation and various fixes.
I split up the xen side patch into 4 smaller ones and cleaned them up.
Linux side patch is same as previous one.
The issue is the complexity and the multi page
I'll apply these if Alex and Hollis will ack them.
-- Keir
On 13/8/07 04:59, Isaku Yamahata [EMAIL PROTECTED] wrote:
This updated patch series is for xencomm consolidation and various fixes
based on Hollis's comment.
Changes from take 1:
xen side varisous fixes and preparation for
On 13/8/07 13:44, Alex Williamson [EMAIL PROTECTED] wrote:
On Mon, 2007-08-13 at 10:10 +0100, Keir Fraser wrote:
I'll apply these if Alex and Hollis will ack them.
They look OK to me.
Acked-by: Alex Williamson [EMAIL PROTECTED]
Okay, just needs someone from the PPC side to comment
On 9/7/07 10:03, Jan Beulich [EMAIL PROTECTED] wrote:
We've already fixed all the shared structures (e.g. sysctl) to use
explicitly-sized types, so the PowerPC port has always had proper
interfaces. For example, look at the definition of xen_ulong_t on the
different architectures. The x86
On 9/7/07 16:45, Hollis Blanchard [EMAIL PROTECTED] wrote:
My mistake, I meant to send this separately.
In 2.6.17, we did our own locking inside direct_remap_pfn_range(). In
the current Linux tree though, the locking is done in privcmd_ioctl().
However, since direct_remap_pfn_range()
On 9/7/07 20:20, Hollis Blanchard [EMAIL PROTECTED] wrote:
By the way, I wonder how PPC manages to build both drivers/char/mem.c and
drivers/xen/char/mem.c without ARCH_HAS_DEV_MEM? The model is supposed to be
that mem_fops defined by the Xen file is picked up by the generic file. If
Changes inside powerpc files are fine. Obviously powerpc-specific changes
inside common files are usually fine. Changes to locking protocols in common
files (e.g., changed usage of mmap_sem in privcmd.c) is *not* fine. Please
post patches for that kind of thing.
-- Keir
On 6/7/07 22:29, Hollis
On 6/7/07 09:09, Jan Beulich [EMAIL PROTECTED] wrote:
--- a/fs/compat_ioctl.c Thu Jul 05 17:25:47 2007 -0500
+++ b/fs/compat_ioctl.c Thu Jul 05 17:26:48 2007 -0500
@@ -2948,6 +2953,18 @@ COMPATIBLE_IOCTL(LPRESET)
/*LPGETSTATS not implemented, but no kernels seem to compile it in anyways*/
Patches 1 thru 4 are applied. This one (patch 5) breaks the x86 build and
even if that is fixed breaks the semantics of gnttab_map()
(apply_to_page_range() is invoked on every call, not just when
shared==NULL).
-- Keir
On 5/7/07 23:27, Hollis Blanchard [EMAIL PROTECTED] wrote:
3 files
On 6/7/07 16:33, Hollis Blanchard [EMAIL PROTECTED] wrote:
Doh, thanks. I have had this locally, but apparently forgot to push
it...
I will apply to the PPC tree, along with a few other changes, and push
upstream later.
Ah, I just threw it into the xen-unstable main tree.
-- Keir
On 5/7/07 22:08, Hollis Blanchard [EMAIL PROTECTED] wrote:
diff -r 001c42f8079e -r e2681868041e drivers/xen/Kconfig
--- a/drivers/xen/Kconfig Thu Jul 05 16:01:18 2007 -0500
+++ b/drivers/xen/Kconfig Thu Jul 05 16:01:18 2007 -0500
@@ -278,4 +278,7 @@ config XEN_BALLOON
bool
default y
CONFIG_COMPAT stuff doesn't belong in include/xen/public/privcmd.h. That
header is shared with userspace so it should stay clean. Make a new one in
include/xen, or in drivers/xen/privcmd, whichever makes most sense.
-- Keir
On 5/7/07 22:08, Hollis Blanchard [EMAIL PROTECTED] wrote:
5 files
On 5/7/07 22:35, Hollis Blanchard [EMAIL PROTECTED] wrote:
+config XEN_XENCOMM
+ bool
+
Shouldn't this have a 'depends on', and 'default y'?
This will be selected by architectures that need it.
If that means it is automatically be handled by the build system and won't
appear in 'make
On 5/7/07 22:08, Hollis Blanchard [EMAIL PROTECTED] wrote:
[XEN][LINUX] #ifdef x86-specific alloc_vm_area().
Since neither IA64 nor PowerPC wants this code, in the future it should really
be moved out of drivers/xen/
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
The IA64 version will get
On 11/6/07 17:42, Hollis Blanchard [EMAIL PROTECTED] wrote:
The net is that I would like to remove the above test. I wonder why it
was added in the first place? Somebody has a privileged autotranslate
domain and mistakenly tried to run the domain building tools?
Interesting. How does this
On 5/4/07 16:56, Keir Fraser [EMAIL PROTECTED] wrote:
On 5/4/07 16:44, Hollis Blanchard [EMAIL PROTECTED] wrote:
This is an interface problem: using the interface in a way that works on
x86 fails on other architectures. PLEASE let's redefine the interface to
prevent this from happening
On 21/3/07 23:48, Hollis Blanchard [EMAIL PROTECTED] wrote:
Hi Keir, please pull from
http://xenbits.xensource.com/ext/xenppc-unstable-merge.hg
Done.
It looks like that will bring in about 775 changesets without changing
any code, but that's the amount of work you would have gotten all
On 9/3/07 21:16, Hollis Blanchard [EMAIL PROTECTED] wrote:
So in conclusion, I think we'll need the legacy behavior, though it
might be interesting for us in the future to modify Linux to use hcalls
to create timer events.
Okay. That¹s where Jeremy is going with the paravirt_ops patches
The xenppc-unstable is already merged and fixed.
-- Keir
On 5/3/07 19:24, Hollis Blanchard [EMAIL PROTECTED] wrote:
There are two patches that touch common code:
* Add a guest_physmap hook for max_mem changes. We've finally
gotten around to removing a hack we've carried in
On 26/2/07 23:31, Hollis Blanchard [EMAIL PROTECTED] wrote:
Hi Yamahata-san, thanks very much for your patch!
I'm confused about one thing though: why do we need to take a lock to
read d-grant_table-nr_grant_frames? It's a simple integer, so no lock
is required or useful.
I haven't got
On 27/2/07 00:05, Hollis Blanchard [EMAIL PROTECTED] wrote:
I don't believe that's a concern, since updating
grant_table-nr_grant_frames is the very last step in
gnttab_grow_table(), and it will only grow.
If there's a memory barrier before the update of nr_grant_frames, explicitly
or
On 19/1/07 17:50, Hollis Blanchard [EMAIL PROTECTED] wrote:
This patch breaks PowerPC, which does not supply arch_(get|
set)hvm_ctxt(). In fact, I don't see where IA64 supplies these either.
Please revert and refactor into arch_do_domctl(), thanks.
Now done.
K.
On 15/12/06 17:27, Hollis Blanchard [EMAIL PROTECTED] wrote:
We recently uncovered a bug on PowerPC where if a timer tick arrives
just inside schedule() while interrupts are still enabled, the
decrementer is never reprogrammed to that appropriate value. This is
because once inside schedule(),
On 15/12/06 20:41, Hollis Blanchard [EMAIL PROTECTED] wrote:
It's an issue with any architecture with a large number of registers
which aren't automatically saved by hardware (and a C ABI that makes
some of them non-volatile).
x86 has a small number of registers. ia64 automatically saves
On 8/12/06 8:25 pm, Hollis Blanchard [EMAIL PROTECTED] wrote:
Allocate shadow memory for PPC Linux domains.
Signed-off-by: Hollis Blanchard [EMAIL PROTECTED]
Just check all these patches into the PPC tree and I¹ll merge them into
unstable with the rest. I always check the diff when I merge
On 13/11/06 8:50 pm, Jimi Xenidis [EMAIL PROTECTED] wrote:
auto-translate guests can use remap_pfn_range() rather than
direct_remap_pfn_range().
This change was specifically made so that mmap of /dev/mem would work (i.e.,
mapping of I/O memory) on mini-xen (dom0 guest running on minimal
On 10/11/06 5:49 am, Isaku Yamahata [EMAIL PROTECTED] wrote:
fix xenmem hypercall for non-trivial xencomm arch(i.e. ia64, and powerpc)
On ia64 and powerpc, guest_handle_add_offset() effect persists over
hypercall continuation because its consumed offset is recorced in
guest domains memory
On 10/11/06 08:45, Isaku Yamahata [EMAIL PROTECTED] wrote:
- introduce guest_handle_add_offset_after_continuatiton() and
replace guest_handle_add_offset() in memory.c with it.
leave do_multicall() and guest_console_write() as is.
This is the best option I think. But I'm loathe to make it
On 30/10/06 8:51 pm, Jimi Xenidis [EMAIL PROTECTED] wrote:
Immediate questions do come to mind:
Why do we return the MFN on a GNTTABOP_map_grant_ref?
It's the *dev* *bus* *addr*. The one you program into your device's DMA
engine. We can't hide that. Yes, in future it will not necessarily
On 20/10/06 13:29, Gerd Hoffmann [EMAIL PROTECTED] wrote:
I'm not after the xc_get_pfn_list hypercall, but the (appearently?)
other hypercall Keir mentioned ...
Could be xc_domain_memory_increase_reservation() or
xc_domain_memory_populate_physmap() ...
Oh, it's called from xend python
On 18/10/06 10:57 pm, Jimi Xenidis [EMAIL PROTECTED] wrote:
It looks like IA64 has introduced a start_pfn for xc_get_pfn_list().
The PPC port requires this as well since it allows us to fill in the
page_array a little bit at a time.
I can either replicate the IA64 ifdef logic (yuk!) or we
On 19/10/06 14:12, Jimi Xenidis [EMAIL PROTECTED] wrote:
use the start_pfn member of struct xen_domctl_getmemlist
Fix all callers and change xen to pay attention to it, I think I have
the x86-xen patch.
Sure. Actually this interface is going away for x86, but not in the
immediate future.
On 19/10/06 14:54, Jimi Xenidis [EMAIL PROTECTED] wrote:
use the start_pfn member of struct xen_domctl_getmemlist
Fix all callers and change xen to pay attention to it, I think I have
the x86-xen patch.
Sure. Actually this interface is going away for x86, but not in the
immediate
On 29/9/06 5:52 am, Hollis Blanchard [EMAIL PROTECTED] wrote:
1: Instead of using a dated snapshot (which no longer exists)
use buildroot-snapshot.
2: Remove hardcoded references to i386.
3: Rename configs/buildroot - configs/buildroot-i386
and update Makefiles.
With patches
On 22/9/06 4:07 pm, Jimi Xenidis [EMAIL PROTECTED] wrote:
--text follows this line--
This patch allows the caller to find out if the gdbstub actually did
anything.
Signed-off-by: Jimi Xenidis [EMAIL PROTECTED]
What different actions do you envisage the caller will take? If they are
On 12/9/06 14:05, Jimi Xenidis [EMAIL PROTECTED] wrote:
Xenconsoled's mapping of the console page should keep the domain
alive.
hmm, I'm having trouble associating the mapping and a refcount of
some sort somewhere, any pointers?
See share_xen_page_with_guest() in arch/x86/mm.c. The
On 27/8/06 11:01 pm, Jimi Xenidis [EMAIL PROTECTED] wrote:
Any response to this?
http://lists.xensource.com/archives/html/xen-devel/2006-08/
msg01315.html
It's fine. I'm just behind on applying patches.
-- Keir
___
Xen-ppc-devel mailing
On 21/8/06 9:03 am, Tristan Gingold [EMAIL PROTECTED] wrote:
xencomm is the ppc infrastructure to do hypercalls with guest physical
addresses instead of virtual address.
Because ia64 should also use physicall address, I think it's better to re-use
the ppc code and to put into common
On 21/8/06 10:20 am, Tristan Gingold [EMAIL PROTECTED] wrote:
Fine in principle. Specific comments:
* powerpc should be cleaned up at the same time to use the common
infrastructure. I don't want duplicated code hanging around in arch/powerpc
I have attached a blindly-made patch again
On 16/8/06 1:30 am, Hollis Blanchard [EMAIL PROTECTED] wrote:
Looks like I bungled this whitespace; could you fix when you commit
please?
It would probably be best to combine this patch with the ia64 patch and
put both our signed-off lines on it. (I'll sign off on Alex's changes,
FWIW.)
On 16/8/06 2:59 pm, Alex Williamson [EMAIL PROTECTED] wrote:
In general this looks a lot better, but I think ia64 is still going
to have trouble with the chunk below. It seems that a VGA card
operating in a standard text mode doesn't necessarily respond to all of
these addresses. On
On 28 Jul 2006, at 20:17, Hollis Blanchard wrote:
I'm not sure this is the best way. We'll need to do the same thing for
xc_ppc_linux_build.c, but it seems a little silly to unconditionally
include powerpc/Makefile as well... perhaps
-include $(XEN_TARGET_ARCH)/Makefile
would suffice?
48 matches
Mail list logo
