search for: superpage

Does upstream dom0 support superpage? best regards yang

This patch enables support of hugepages in a pv Xen environment. It is against the latest xen unstable tree on http://xenbits.xensource.com. The patch assumes the guest is passing a physically aligned hugepage. It does reference counting on all the underlying pages. Dave McCracken Oracle Corp. _______________________________________________ Xen-devel mailing list

This patch series includes a series of bugs related to p2m, ept, and PoD code which were found as part of our XenServer product testing. Each of these fixes actual bugs, and the 3.4-based version of the patch has been tested thoroughly. (There may be bugs in porting the patches, but most of them are simple enough as to make it unlikely.) Each patch is conceptually independent, so they can each

The PV superpage mapping feature has been in the hypervisor for a while now, but I''m not away of any use of this feature by an upstream guest kernel (e.g., and primarily of interest, pv_ops Linux). Am I mistaken, or is anyone looking into or interested in this? If the feature is unused we should remove it...

This patch series adds support for preservation of the VM generation ID buffer address in xenstore across save/restore and migrate, and also code to increment the value in all cases except for migration. The first patch modifies creation of the hvmloader key in xenstore and adds creation of a new read/write hvmloader/generation-id-addr key. The second patch changes hvmloader to use the new key (as

Populate-on-demand: Check pages being returned by the balloon driver This patch series is the second result of my work last summer on decreasing fragmentation of superpages in a guests'' p2m when using populate-on-demand. This patch series is against 4.1; I''m posting it to get feedback on the viability of getting a ported version of this patch into 4.2. As with the previous series, the patces against 4.1 have been extensively in the XenServer testi...

This patch series adds support for preservation of the VM generation ID buffer address in xenstore across save/restore and migrate, and also code to increment the value in all cases except for migration. The vast majority of the code is in second patch. The first patch merely changes the xenstore key name used by hvmloader to store the buffer address.

This patch series adds support for preservation of the VM generation ID buffer address in xenstore across save/restore and migrate, and also code to increment the value in all cases except for migration. Patch 1 modifies the guest ro and rw node creation to an open coding style and cleans up some extraneous node creation. Patch 2 modifies creation of the hvmloader key in xenstore and adds

This patch series restores the use of superpages when restoring or migrating a VM, while retaining efficient batching of 4k pages when superpages are not appropriate or available. Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com...

...<george.dunlap@eu.citrix.com> > > diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c > --- a/xen/arch/x86/mm/p2m-pod.c > +++ b/xen/arch/x86/mm/p2m-pod.c > @@ -909,6 +909,27 @@ p2m_pod_emergency_sweep_super(struct p2m > p2m->pod.reclaim_super = i ? i - SUPERPAGE_PAGES : 0; > } > > +/* When populating a new superpage, look at recently populated superpages > + * hoping that they''ve been zeroed. This will snap up zeroed pages as > soon as > + * the guest OS is done with them. */ > +static void > +p2m_pod_check_last_super(str...

We have implemented hugepage support for guests in following manner In our implementation we added a parameter hugepage_num which is specified in the config file of the DomU. It is the number of hugepages that the guest is guaranteed to receive whenever the kernel asks for hugepage by using its boot time parameter or reserving after booting (eg. Using echo XX > /proc/sys/vm/nr_hugepages).

...dom, uint32_t max_iters, > ^ > xenguest_stubs.c: In function 'stub_xc_domain_restore': > xenguest_stubs.c:552:10: warning: passing argument 7 of 'xc_domain_restore' makes integer from pointer without a cast [enabled by default] > Bool_val(hvm), f.pae, 0 /*superpages*/); > ^ > In file included from xenguest_stubs.c:23:0: > /usr/include/xenguest.h:122:5: note: expected 'unsigned int' but argument is of type 'long unsigned int *' > int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom, > ^ > xenguest_s...

Hi all, This is today''s nightly testing report; no new issue found, bug #1259 got fixed. Some vt-d cases failed in first round testing, but can get pass in retesting. Fixed issue: ============================================== 1. booting windows guest causes Xen HV crash http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1259 Old issues:

The following is a revised patch series to add support for a VM generation ID virtual device for HVM guests. The basic requirements of this device are as follows: - It must be exposed somewhere in ACPI namespace with a _CID of "VM_Gen_Counter". - It must also include a _DDN of "VM_Gen_Counter". - It must contain a _HID object but no particular value is required. - It must

...= > /boot/initrd.img-2.6.32.27-xen-domU > [2011-01-23 15:36:01 3201] DEBUG (image:728) vcpus = 1 > [2011-01-23 15:36:01 3201] DEBUG (image:729) features = > [2011-01-23 15:36:01 3201] DEBUG (image:730) flags = 0 > [2011-01-23 15:36:01 3201] DEBUG (image:731) superpages = 0 > [2011-01-23 15:36:02 3201] ERROR (XendDomainInfo:2909) > XendDomainInfo.initDomain: exception occurred > Traceback (most recent call last): > File "/usr/lib/xen-4.0/bin/../lib/python/xen/xend/XendDomainInfo.py", > line 2880, in _initDomain > channel_deta...

...= > /boot/initrd.img-2.6.32.27-xen-domU > [2011-01-23 15:36:01 3201] DEBUG (image:728) vcpus = 1 > [2011-01-23 15:36:01 3201] DEBUG (image:729) features = > [2011-01-23 15:36:01 3201] DEBUG (image:730) flags = 0 > [2011-01-23 15:36:01 3201] DEBUG (image:731) superpages = 0 > [2011-01-23 15:36:02 3201] ERROR (XendDomainInfo:2909) > XendDomainInfo.initDomain: exception occurred > Traceback (most recent call last): > File "/usr/lib/xen-4.0/bin/../lib/python/xen/xend/XendDomainInfo.py", > line 2880, in _initDomain > channel_deta...

On 09/24/2013 10:04 PM, St?phane Glondu wrote: > Le 24/09/2013 15:48, St?phane Glondu a ?crit : >> If I remove all binary packages of xen-api from testing, the following >> new packages are broken: xcp-guest-templates, nova-xcp-plugins, >> nova-compute-xen. >> >> xcp-guest-templates is built by guest-templates which seems to be a leaf >> package and could be

I'm trying to upgrade an 11 month old FreeBSD 7 image in a VMware 4.5.2 guest to an up-to-date -stable and it panics as above. I've added a printf to report the two counts and there's a difference of one page. I don't have any problems with the old 7-stable image or up-to-date 6-stable or -current using the same VMware version. A screendump for a verbose boot can be found at

Hi there, We are using latest version of XCP on 6 hosts. While issuing VM.start or VM.start_on xmlrpc functional call , it says : {''Status'': ''Failure'', ''ErrorDescription'': [''SESSION_INVALID'', ''OpaqueRef:cfb6df14-387d-40a1-cc27-d5962cba7712'']} However if I put VM.start in a loop maybe after

On Fri, Aug 30, 2019 at 4:54 AM Fāng-ruì Sòng <maskray at google.com> wrote: > > > Old: R RX RW(RELRO) RW > > > New: R(R+RELRO) RX RW; R includes the traditional R part and the > > > RELRO part > > > Runtime (before relocation resolving): RW RX RW > > > Runtime (after relocation resolving): R RX RW > > > > > I actually see two