search for: nr_mfns

...n/mmu.c b/arch/x86/xen/mmu.c index b4be4c9..fbf6a63 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -333,20 +333,6 @@ static void xen_set_pte(pte_t *ptep, pte_t pteval) __xen_set_pte(ptep, pteval); } -void xen_set_clr_mmio_pvh_pte(unsigned long pfn, unsigned long mfn, - int nr_mfns, int add_mapping) -{ - struct physdev_map_iomem iomem; - - iomem.first_gfn = pfn; - iomem.first_mfn = mfn; - iomem.nr_mfns = nr_mfns; - iomem.add_mapping = add_mapping; - - if (HYPERVISOR_physdev_op(PHYSDEVOP_map_iomem, &iomem)) - BUG(); -} - static void xen_set_pte_at(struct mm_struct *mm, u...

...:0 INTA->IRQ10 (XEN) HVM4: pci dev 02:0 bar 10 size 02000000: f0000008 (XEN) HVM4: pci dev 03:0 bar 14 size 01000000: f2000008 (XEN) HVM4: pci dev 04:0 bar 30 size 00080000: f3000000 (XEN) HVM4: pci dev 05:0 bar 30 size 00080000: f3080000 (XEN) domctl.c:985:d0 memory_map:add: gfn=f3100 mfn=df040 nr_mfns=40 (XEN) HVM4: pci dev 04:0 bar 1c size 00040000: f3100004 (XEN) domctl.c:985:d0 memory_map:add: gfn=f3140 mfn=df640 nr_mfns=40 (XEN) HVM4: pci dev 05:0 bar 1c size 00040000: f3140004 (XEN) domctl.c:985:d0 memory_map:add: gfn=f3180 mfn=df03c nr_mfns=4 (XEN) domctl.c:995:d0 memory_map:remove: gfn=f3...

These two patches were originally part of the XSM series that I have posted, and remain prerequisites for that series. However, they are independent of the XSM changes and are a useful simplification regardless of the use of XSM. The Acked-bys on these patches were provided before rebasing them over the copyback changes in 26268:1b72138bddda, which had minor conflicts that I resolved. [PATCH

(moving to xen-devel, xen-arm is for the older PV ARM port) On Tue, 2013-06-25 at 23:59 +0000, Eric Trudeau wrote: > Hi, I am trying to build the XEN tools for our port of XEN to our > Cortex A15-based platform. > > I am using the repo at git://xenbits.xenproject.org/xen.git to > cross-compile the tools into our rootfs. Which branch/changeset are you using? I've heard that

...HVM1: pci dev 03:0 INTC->IRQ10 (XEN) HVM1: pci dev 04:0 INTA->IRQ5 (XEN) HVM1: pci dev 02:0 bar 10 size 02000000: f0000008 (XEN) HVM1: pci dev 03:0 bar 14 size 01000000: f2000008 (XEN) HVM1: pci dev 05:0 bar 10 size 00004000: f3000004 (XEN) domctl.c:982:d0 memory_map:add: gfn=f3000 mfn=dd5a0 nr_mfns=4 (XEN) domctl.c:982:d0 memory_map:add: gfn=f3004 mfn=dd6a0 nr_mfns=4 (XEN) domctl.c:992:d0 memory_map:remove: gfn=f3004 mfn=dd6a0 nr_mfns=1 (XEN) HVM1: pci dev 05:0 bar 1c size 00004000: f3004004 (XEN) HVM1: pci dev 02:0 bar 14 size 00001000: f3008000 (XEN) HVM1: pci dev 03:0 bar 10 size 00000100:...

Instead, propagate the condition to the caller, all of which also get adjusted to check for that situation. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- 2011-03-09.orig/xen/arch/x86/mm.c +++ 2011-03-09/xen/arch/x86/mm.c @@ -5141,8 +5141,11 @@ int map_pages_to_xen( while ( nr_mfns != 0 ) { #ifdef __x86_64__ - l3_pgentry_t *pl3e = virt_to_xen_l3e(virt); - l3_pgentry_t ol3e = *pl3e; + l3_pgentry_t ol3e, *pl3e = virt_to_xen_l3e(virt); + + if ( !pl3e ) + return -ENOMEM; + ol3e = *pl3e; if ( cpu_has_page1gb &&...

...MCTL_INTERFACE_VERSION 0x00000004 +#define XEN_DOMCTL_INTERFACE_VERSION 0x00000005 struct xenctl_cpumap { XEN_GUEST_HANDLE(uint8_t) bitmap; @@ -341,6 +337,11 @@ struct xen_domctl_iomem_permission { uint64_t first_mfn; /* first page (physical page number) in range */ uint64_t nr_mfns; /* number of pages in range (>0) */ uint8_t allow_access; /* allow (!0) or deny (0) access to range? */ +#define IOMEM_ACCESS_NOACCESS 0 +#define IOMEM_ACCESS_READWRITE 1 +#define IOMEM_ACCESS_READONLY 2 + uint8_t rw; /* read/write permissions to allow. +...

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 http://lists.xensource.com/xen-devel

Hello, It looks like upstream linux-2.6.git contains at least the following xen related new features for Linux 2.6.36: - Xen-SWIOTLB support (required for Xen PCI passthru and dom0) - Xen PV-on-HVM drivers - Xen VBD online dynamic resize of guest disks (xvd*) Congratulations! What are the plans for 2.6.37 merge window? I believe at least: - Xen PCI frontend Others? I''m going to

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Hi all, This series adds a new microcode driver for Xen. The Xen hypervisor can deal with all the low-level details of doing a microcode update (Intel vs AMD, doing all the physical CPUs present on the system, current and future, etc), so all the driver has to do is make a hypercall to upload the microcode into Xen. This only

...link 3 routed to IRQ5 (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c001 (XEN) io.c:157:d32767 hvm_dpci_eoi:: device 2 intx 0 (XEN) HVM1: pci dev 01:2 INTA->IRQ10 (XEN) HVM1: pci dev 02:0 bar 10 size 00080000: f0000000 (XEN) domctl.c:595:d0 memory_map:add: gfn=f0000 mfn=90480 nr_mfns=80 (XEN) HVM1: pci dev 02:0 bar 14 size 00000008: 0000c011 (XEN) domctl.c:646:d0 ioport_map:add f_gport=c010 f_mport=3410 np=8 (XEN) HVM1: pci dev 02:0 bar 18 size 10000000: 00000008 (XEN) domctl.c:595:d0 memory_map:add: gfn=10000 mfn=90300 nr_mfns=100 (XEN) HVM1: pci dev 02:0 bar 1c...

On Thu, 17 Jan 2013 22:22:47 -0500 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > Jan had some comments about that patch: > > https://patchwork.kernel.org/patch/1745041/ > > Please fix it up so I can put it in the Linux tree. Please see below. Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com> Thanks, Mukesh diff --git a/arch/x86/xen/xen-head.S

This patch supports basic gfx passthrough on QEMU: - disable emulated VGA adpater if there is passthroughed gfx - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx Signed-off-by: Ben Lin <ben.y.lin@intel.com> Signed-off-by: Weidong Han <weidong.han@intel.com> _______________________________________________ Xen-devel mailing list

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

...pedef struct xen_domctl_irq_permission xen_domctl_irq_permission_t; +DEFINE_XEN_GUEST_HANDLE(xen_domctl_irq_permission_t); + + +#define XEN_DOMCTL_iomem_permission 20 +struct xen_domctl_iomem_permission { + uint64_t first_mfn; /* first page (physical page number) in range */ + uint64_t nr_mfns; /* number of pages in range (>0) */ + uint8_t allow_access; /* allow (!0) or deny (0) access to range? */ +}; +typedef struct xen_domctl_iomem_permission xen_domctl_iomem_permission_t; +DEFINE_XEN_GUEST_HANDLE(xen_domctl_iomem_permission_t); + + +#define XEN_DOMCTL_ioport_permiss...

Hello everyone, this is the fourth version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

Hello everyone, this is the very first version of the patch series that introduces ARMv7 with virtualization extensions support in Xen. The series allows Xen and Dom0 to boot on a Cortex-A15 based Versatile Express simulator. See the following announce email for more informations about what we are trying to achieve, as well as the original git history: See

This patch series implements SMP boot for arch/arm, as far as getting all CPUs up and running the idle loop. Changes from v1: - moved barriers out of loop in udelay() - dropped broken GIC change in favour of explanatory comment - made the increment of ready_cpus atomic (I couldn''t move the increment to before signalling the next CPU because the PT switch has to happen between

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine

Hi, V6: The only change from V5 is in patch #6: - changed comment to reflect autoxlate - removed a redundant ASSERT - reworked logic a bit so that get_page_from_gfn() is called with NULL for p2m type as before. arm has ASSERT wanting it to be NULL. Tim: patch 4 needs your approval. Daniel: patch 5 needs your approval. These patches implement PVH dom0. Patches 1 and 2