All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel <xen-devel@lists.xen.org>,
	Jan Beulich <JBeulich@suse.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Is: PVH + ARM new hypercalls. Was: Re: [PATCH]: PVH: specify xen features strings cleany for PVH
Date: Mon, 28 Jan 2013 11:26:08 -0500	[thread overview]
Message-ID: <20130128162607.GA7223@konrad-lan.dumpdata.com> (raw)
In-Reply-To: <1359110621.10051.25.camel@zakaz.uk.xensource.com>

On Fri, Jan 25, 2013 at 10:43:41AM +0000, Ian Campbell wrote:
> On Fri, 2013-01-25 at 10:27 +0000, Jan Beulich wrote:
> > >>> On 25.01.13 at 11:11, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > > On Fri, 2013-01-25 at 08:02 +0000, Jan Beulich wrote:
> > >> >>> On 25.01.13 at 00:13, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> > >> > This is on top of what konrad already has in his linux tree so he
> > >> > can just apply it. Here's the final version of the file, just in case:
> > >> 
> > >> Looks okay to me, and I don't mind whether this
> > >> 
> > >> >         ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,       .ascii 
> > >> > "!writable_page_tables|pae_pgdir_above_4gb"; .asciz PVH_FEATURES_STR);
> > >> 
> > >> is done using the .ascii/.asciz or the simpler string concatenation
> > >> way, as long as the latter works.
> > > 
> > > String concat in gas doesn't work like in C, you get a \0 at the join...
> > 
> > But this is going through the C preprocessor, and that one,
> > according to all I know, ought to concatenate adjacent strings.
> 
> I don't think so, turning
>         "Foo" "Bar"
> into
>         "FooBar"
> happens at the C level not the CPP level.
> 
>         #define FOO(x) x
>         FOO(.asciz "Foo" "Bar")
>         
>         #define CAT(x,y) x y
>         FOO(.asciz CAT("Foo","Bar"))
>         
>         #define CAT2(x,y) x #y
>         FOO(CAT2(.asciz, Foo Bar))
> will produce
>         .asciz "Foo" "Bar"
>         .asciz "Foo" "Bar"
>         .asciz "Foo Bar"
> 
> (where FOO(x) ~= ELFNOTE(..., x))
> 
> The third form might be an alternative fix to this issue but I don't
> think it is any better than the .ascii/.asciz solution.

OK. So I stuck Mukesh's patch in the tree along with yours:

http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/stable/pvh.v7

and all of that on top of v3.8-rc5:

http://git.kernel.org/?p=linux/kernel/git/konrad/xen.git;a=shortlog;h=refs/heads/linux-next

We still have a couple of weeks before we have to make the
go/no-go decision on the the new hypercalls:


#define XENMEM_add_to_physmap_range 23
struct xen_add_to_physmap_range {
    /* IN */
    /* Which domain to change the mapping for. */
    domid_t domid;
    uint16_t space; /* => enum phys_map_space */

    /* Number of pages to go through */
    uint16_t size;
    domid_t foreign_domid; /* IFF gmfn_foreign */

    /* Indexes into space being mapped. */
    GUEST_HANDLE(xen_ulong_t) idxs;

    /* GPFN in domid where the source mapping page should appear. */
    GUEST_HANDLE(xen_pfn_t) gpfns;

    /* OUT */

    /* Per index error code. */
    GUEST_HANDLE(int) errs;
};


/*
 * Unmaps the page appearing at a particular GPFN from the specified guest's
 * pseudophysical address space.
 * arg == addr of xen_remove_from_physmap_t.
 */
#define XENMEM_remove_from_physmap      15
struct xen_remove_from_physmap {
    /* Which domain to change the mapping for. */
    domid_t domid;

    /* GPFN of the current mapping of the page. */
    xen_pfn_t gpfn;
};
DEFINE_GUEST_HANDLE_STRUCT(xen_remove_from_physmap);


/*
 * Returns the location in virtual address space of the machine_to_phys
 * mapping table. Architectures which do not have a m2p table, or which do not
 * map it by default into guest address space, do not implement this command.
 * arg == addr of xen_machphys_mapping_t.
 */
#define XENMEM_machphys_mapping     12
struct xen_machphys_mapping {
    xen_ulong_t v_start, v_end; /* Start and end virtual addresses.   */
    xen_ulong_t max_mfn;        /* Maximum MFN that can be looked up. */
};


#define PHYSDEVOP_map_iomem        30
struct physdev_map_iomem {
    /* IN */
    uint64_t first_gfn;
    uint64_t first_mfn;
    uint32_t nr_mfns;
    uint32_t add_mapping; /* 1 == add mapping;  0 == unmap */

};

and the modification to one:

commit 50c0b3df91be7a440b50ee7d74fd2042bca173fd
Author: Mukesh Rathor <mukesh.rathor@oracle.com>
Date:   Mon Oct 22 11:37:57 2012 -0400

    xen/pvh: Extend vcpu_guest_context, p2m, event, and XenBus.
    
    Make gdt_frames[]/gdt_ents into a union with {gdtaddr, gdtsz},
    as PVH only needs to send down gdtaddr and gdtsz in the
    vcpu_guest_context structure..
    
    For interrupts, PVH uses native_irq_ops so we can skip most of the
    PV ones. In the future we can support the pirq_eoi_map..
    Also VCPU hotplug is currently not available for PVH.
    
    For events (and IRQs) we follow what PVHVM does - so use callback
    vector.  Lastly, for XenBus we use the same logic that is used in
    the PVHVM case.
    
    Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
    [v2: Rebased it]
    [v3: Move 64-bit ifdef and based on Stefan add extra comments.]
    [v4: Rebased it once more]
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index fd9cb76..20e738a 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -145,7 +145,16 @@ struct vcpu_guest_context {
     struct cpu_user_regs user_regs;         /* User-level CPU registers     */
     struct trap_info trap_ctxt[256];        /* Virtual IDT                  */
     unsigned long ldt_base, ldt_ents;       /* LDT (linear address, # ents) */
-    unsigned long gdt_frames[16], gdt_ents; /* GDT (machine frames, # ents) */
+    union {
+	struct {
+		/* PV: GDT (machine frames, # ents).*/
+		unsigned long gdt_frames[16], gdt_ents;
+	} pv;
+	struct {
+		/* PVH: GDTR addr and size */
+		unsigned long gdtaddr, gdtsz;
+	} pvh;
+    } u;
     unsigned long kernel_ss, kernel_sp;     /* Virtual TSS (only SS1/SP1)   */
     /* NB. User pagetable on x86/64 is placed in ctrlreg[1]. */
     unsigned long ctrlreg[8];               /* CR0-CR7 (control registers)  */
> 
> Ian.
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

  reply	other threads:[~2013-01-28 16:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-19  1:35 [PATCH]: PVH: specify xen features strings cleany for PVH Mukesh Rathor
2013-01-21 12:06 ` Jan Beulich
2013-01-22 23:12   ` Mukesh Rathor
2013-01-23  8:22     ` Jan Beulich
2013-01-23 22:43       ` Mukesh Rathor
2013-01-24  9:16         ` Jan Beulich
2013-01-24  9:27           ` Ian Campbell
2013-01-24 15:10             ` Konrad Rzeszutek Wilk
2013-01-24 23:13           ` Mukesh Rathor
2013-01-25  8:02             ` Jan Beulich
2013-01-25 10:11               ` Ian Campbell
2013-01-25 10:27                 ` Jan Beulich
2013-01-25 10:43                   ` Ian Campbell
2013-01-28 16:26                     ` Konrad Rzeszutek Wilk [this message]
2013-01-29  2:57                       ` Is: PVH + ARM new hypercalls. Was: " Mukesh Rathor
2013-01-29 10:48                         ` Jan Beulich
2013-02-01  2:23                           ` Mukesh Rathor
2013-02-01 16:24                             ` Jan Beulich
2013-02-01 19:27                               ` Mukesh Rathor
2013-02-04 10:31                                 ` Ian Campbell
2013-02-05  1:04                                   ` Mukesh Rathor
2013-02-05  7:53                                     ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130128162607.GA7223@konrad-lan.dumpdata.com \
    --to=konrad@kernel.org \
    --cc=Ian.Campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.