From: Mukesh Rathor <mukesh.rathor@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 11/20] PVH xen: introduce pvh.c
Date: Thu, 16 May 2013 17:27:21 -0700 [thread overview]
Message-ID: <20130516172721.74867731@mantra.us.oracle.com> (raw)
In-Reply-To: <5194AE4C02000078000D6A2D@nat28.tlf.novell.com>
On Thu, 16 May 2013 09:00:44 +0100
"Jan Beulich" <JBeulich@suse.com> wrote:
> >>> On 16.05.13 at 03:42, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -1129,6 +1129,10 @@ arch_do_vcpu_op(
> > struct domain *d = v->domain;
> > struct vcpu_register_vcpu_info info;
> >
> > + rc = -ENOSYS;
> > + if ( is_pvh_vcpu(current) )
> > + break;
> > +
>
> Assuming this is meant to be temporary - yes, this _might_ be
> acceptable (if accompanied by a proper comment). But then again
> registering vCPU info is a pretty basic interface (which recently
> got even moved into common code iirc), so I'm having a hard time
> seeing why you need to suppress it rather than make it work from
> the beginning.
Because I am not as smart as you, and my brain gets full sooner :). I
only know to do big features in pieces. As it is already, each refresh
costs me days to merge, resolving conflicts, looking at code to see what
changed, etc.. then almost always something breaks, and takes a while
to debug. I got linux side patch to watch out too.
My understanding with previous maintainers was, establish a baseline with
something working, then keep adding bells and whistles to it. This is an
effort to that end. I am also OK dropping the ball on pvh and let
someones else who can finish it all in one shot do it.
Thanks again for all your time and input, you are thorough :).
Mukesh
next prev parent reply other threads:[~2013-05-17 0:27 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-15 0:52 [PATCH 00/20][V5]: PVH xen: version 5 patches Mukesh Rathor
2013-05-15 0:52 ` [PATCH 01/20] PVH xen: turn gdb_frames/gdt_ents into union Mukesh Rathor
2013-05-15 0:52 ` [PATCH 02/20] PVH xen: add XENMEM_add_to_physmap_range Mukesh Rathor
2013-05-15 9:58 ` Jan Beulich
2013-05-15 23:05 ` Mukesh Rathor
2013-05-16 7:21 ` Jan Beulich
2013-05-16 11:03 ` Stefano Stabellini
2013-05-16 12:01 ` Jan Beulich
2013-05-16 15:04 ` Stefano Stabellini
2013-05-16 23:56 ` Mukesh Rathor
2013-05-17 6:37 ` Jan Beulich
2013-05-17 22:24 ` Mukesh Rathor
2013-05-15 0:52 ` [PATCH 03/20] PVH xen: create domctl_memory_mapping() function Mukesh Rathor
2013-05-15 10:07 ` Jan Beulich
2013-05-15 0:52 ` [PATCH 04/20] PVH xen: add params to read_segment_register Mukesh Rathor
2013-05-15 0:52 ` [PATCH 05/20] PVH xen: vmx realted preparatory changes for PVH Mukesh Rathor
2013-05-15 0:52 ` [PATCH 06/20] PVH xen: Move e820 fields out of pv_domain struct Mukesh Rathor
2013-05-15 10:27 ` Jan Beulich
2013-05-15 0:52 ` [PATCH 07/20] PVH xen: Introduce PVH guest type Mukesh Rathor
2013-05-15 0:52 ` [PATCH 08/20] PVH xen: tools changes to create PVH domain Mukesh Rathor
2013-05-15 0:52 ` [PATCH 09/20] PVH xen: domain creation code changes Mukesh Rathor
2013-05-15 0:52 ` [PATCH 10/20] PVH xen: create PVH vmcs, and also initialization Mukesh Rathor
2013-05-15 0:52 ` [PATCH 11/20] PVH xen: introduce pvh.c Mukesh Rathor
2013-05-15 10:42 ` Jan Beulich
2013-05-16 1:42 ` Mukesh Rathor
2013-05-16 8:00 ` Jan Beulich
2013-05-17 0:27 ` Mukesh Rathor [this message]
2013-05-17 6:43 ` Jan Beulich
2013-05-21 0:08 ` Mukesh Rathor
2013-05-21 7:07 ` Jan Beulich
2013-05-15 0:52 ` [PATCH 12/20] PVH xen: create read_descriptor_sel() Mukesh Rathor
2013-05-15 0:52 ` [PATCH 13/20] PVH xen: introduce vmx_pvh.c Mukesh Rathor
2013-05-15 11:46 ` Jan Beulich
2013-05-15 0:52 ` [PATCH 14/20] PVH xen: some misc changes like mtrr, intr, msi Mukesh Rathor
2013-05-15 0:52 ` [PATCH 15/20] PVH xen: hcall page initialize, create PVH guest type, etc Mukesh Rathor
2013-05-15 0:52 ` [PATCH 16/20] PVH xen: Miscellaneous changes Mukesh Rathor
2013-05-15 11:53 ` Jan Beulich
2013-05-16 1:51 ` Mukesh Rathor
2013-05-15 0:52 ` [PATCH 17/20] PVH xen: Introduce p2m_map_foreign Mukesh Rathor
2013-05-15 11:55 ` Jan Beulich
2013-05-15 0:52 ` [PATCH 18/20] PVH xen: Add and remove foreign pages Mukesh Rathor
2013-05-15 12:05 ` Jan Beulich
2013-05-15 0:52 ` [PATCH 19/20] PVH xen: elf and iommu related changes to prep for dom0 PVH Mukesh Rathor
2013-05-15 12:12 ` Jan Beulich
2013-05-16 1:58 ` Mukesh Rathor
2013-05-16 8:03 ` Jan Beulich
2013-05-17 1:14 ` Mukesh Rathor
2013-05-17 6:45 ` Jan Beulich
2013-05-18 2:01 ` Mukesh Rathor
2013-05-21 7:14 ` Jan Beulich
2013-05-15 0:52 ` [PATCH 20/20] PVH xen: PVH dom0 creation Mukesh Rathor
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=20130516172721.74867731@mantra.us.oracle.com \
--to=mukesh.rathor@oracle.com \
--cc=JBeulich@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).