On Fri, Aug 10, 2007 at 01:54:47PM -0500, Hollis Blanchard wrote:
I don't see how we'd ever hit this case though, nor why we'd panic the
domain. How could paddr_to_maddr() ever return an maddr that doesn't
belong to the current domain? If paddr is invalid, an error should be
returned from
On Tue, 2007-08-07 at 17:44 +0900, Isaku Yamahata wrote:
+/* get_page() to prevent from another vcpu freeing the page */
+static int
+xencomm_paddr_to_maddr(unsigned long paddr, unsigned long *maddr,
+struct page_info **page)
+{
+*maddr = paddr_to_maddr(paddr);
+if (*maddr
On Fri, Aug 03, 2007 at 09:43:16AM -0500, Hollis Blanchard wrote:
On Fri, 2007-08-03 at 11:12 +0900, Isaku Yamahata wrote:
On Thu, Aug 02, 2007 at 10:00:46AM -0500, Hollis Blanchard wrote:
On Thu, 2007-08-02 at 11:44 +0900, Isaku Yamahata wrote:
But we can issue sequential p2m
On Thu, 2007-08-02 at 11:44 +0900, Isaku Yamahata wrote:
But we can issue sequential p2m hcalls with different offsets, so we
do.
So what exactly is the new problem?
The limit is about 64GB for xen/ia64 because xen/ia64 deafult page
size
is 16KB.
The issue I'm seeing is the populate
On Tue, Jul 31, 2007 at 02:25:17PM -0600, Alex Williamson wrote:
Should we make the same changes to the common xencomm files?
(xen-ppc-devel CC'd) I don't see why we wouldn't, at least for this
first one.
Yes, that's right.
I attached the updated one and the new patch for common xencomm
On Wed, 2007-08-01 at 15:36 +0900, Isaku Yamahata wrote:
remove xencomm page size limit.
Currently xencomm has page size limit so that a domain with many memory
(e.g. 100GB+) can't be created.
This patch allows that the address array of struct xencomm_desc to cross
page boundary so that the
On Wed, Aug 01, 2007 at 02:07:54PM -0500, Hollis Blanchard wrote:
On Wed, 2007-08-01 at 15:36 +0900, Isaku Yamahata wrote:
remove xencomm page size limit.
Currently xencomm has page size limit so that a domain with many memory
(e.g. 100GB+) can't be created.
This patch allows that the
