ack.
I'm happy to test a 2nd round, if you CC me on any fixed patches (just
in case I'm not monitoring lkml / xen-devel on that particular day)
On Fri, Oct 19, 2012 at 2:49 PM, Konrad Rzeszutek Wilk
wrote:
> On Wed, Oct 17, 2012 at 02:00:29PM -0400, Ben Guthro wrote:
>> I'm not sure it matters,
On Wed, Oct 17, 2012 at 02:00:29PM -0400, Ben Guthro wrote:
> I'm not sure it matters, but I'm testing against a changeset about a week old:
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1c4a5b37b55c56e49135e65728137f54288d1fe6
I was able to reproduce it with Xen 4.2 so found the culprit.
On 10/19/2012 08:48 AM, Konrad Rzeszutek Wilk wrote:
>> paravirtualized architectures out there which are perfectly well
>> documented and supportable, but Xen has resisted doing that for
>> years, and all we ever get are vague future promises.
>
> There is no resistance - and it is being done.
> paravirtualized architectures out there which are perfectly well
> documented and supportable, but Xen has resisted doing that for
> years, and all we ever get are vague future promises.
There is no resistance - and it is being done. Every month we document
various APIs, man-pages, etc so that
paravirtualized architectures out there which are perfectly well
documented and supportable, but Xen has resisted doing that for
years, and all we ever get are vague future promises.
There is no resistance - and it is being done. Every month we document
various APIs, man-pages, etc so that
On 10/19/2012 08:48 AM, Konrad Rzeszutek Wilk wrote:
paravirtualized architectures out there which are perfectly well
documented and supportable, but Xen has resisted doing that for
years, and all we ever get are vague future promises.
There is no resistance - and it is being done. Every
On Wed, Oct 17, 2012 at 02:00:29PM -0400, Ben Guthro wrote:
I'm not sure it matters, but I'm testing against a changeset about a week old:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1c4a5b37b55c56e49135e65728137f54288d1fe6
I was able to reproduce it with Xen 4.2 so found the culprit.
ack.
I'm happy to test a 2nd round, if you CC me on any fixed patches (just
in case I'm not monitoring lkml / xen-devel on that particular day)
On Fri, Oct 19, 2012 at 2:49 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Wed, Oct 17, 2012 at 02:00:29PM -0400, Ben Guthro wrote:
I'm
On 18/10/12 18:42, Konrad Rzeszutek Wilk wrote:
>> As for 'perf', since Xen already provides a virtual PMU for HVM guests
>> It's not clear why we would spend the effort to implement another
>> mechanism for PV guests (instead of using the virtual PMU from a PVH guest).
>
> Would that allow one
> As for 'perf', since Xen already provides a virtual PMU for HVM guests
> It's not clear why we would spend the effort to implement another
> mechanism for PV guests (instead of using the virtual PMU from a PVH guest).
Would that allow one to evaluate the performance/bottlenecks that the
On 10/18/2012 09:44 AM, Stefano Stabellini wrote:
I know that it is obvious but it is worth stating it in clear letters:
these are Dan's personal opinions and by no means represent the position
of the Xen community as a whole on this topic.
I, for one, have no idea what he is talking about.
On Thu, 18 Oct 2012, Borislav Petkov wrote:
> On Thu, Oct 18, 2012 at 08:56:40AM -0700, Dan Magenheimer wrote:
> > I agree the whole idea of paravirtualization is a hack, but it is a
> > hack to workaround some poor architectural design decisions many years
> > ago by Intel processor designers who
On 10/18/2012 08:56 AM, Dan Magenheimer wrote:
Do you notice that the document you just claimed doesn't even exist at
this point, never mind being somehow enforced? In other word, there is
ABSOLUTELY NO WAY a mainline kernel developer can have any idea what
amount of violence Xen does to the
On 17/10/12 17:54, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 17, 2012 at 09:50:11AM -0700, H. Peter Anvin wrote:
>> On 10/17/2012 09:10 AM, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Oct 18, 2012 at 08:56:40AM -0700, Dan Magenheimer wrote:
> I agree the whole idea of paravirtualization is a hack, but it is a
> hack to workaround some poor architectural design decisions many years
> ago by Intel processor designers who should have known better. Go yell
> at them.
>
>
> From: H. Peter Anvin [mailto:h...@zytor.com]
> Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI S3
> and Xen (suprisingly
> small\!).
>
> On 10/18/2012 08:22 AM, Dan Magenheimer wrote:
> >
> > It's a bit more complicated than that.
On 10/18/2012 08:22 AM, Dan Magenheimer wrote:
It's a bit more complicated than that. The problem is that if
any patch is ever submitted to the kernel that uses the rdtscp
instruction *in kernel space* in some clever way, the resultant
kernel may not behave as expected (depending on how the
el] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI S3
> and Xen (suprisingly
> small\!).
>
> On 10/17/2012 09:54 AM, Konrad Rzeszutek Wilk wrote:
> >>
> >> Could you do an audit for other pvops calls that have no users? If
> >> the *only* user
call. Was: Re: [RFC] ACPI S3
and Xen (suprisingly
small\!).
On 10/17/2012 09:54 AM, Konrad Rzeszutek Wilk wrote:
Could you do an audit for other pvops calls that have no users? If
the *only* user is lguest, we should talk about it, too...
I can do that - but I don't want to be hasty
On 10/18/2012 08:22 AM, Dan Magenheimer wrote:
It's a bit more complicated than that. The problem is that if
any patch is ever submitted to the kernel that uses the rdtscp
instruction *in kernel space* in some clever way, the resultant
kernel may not behave as expected (depending on how the
From: H. Peter Anvin [mailto:h...@zytor.com]
Subject: Re: [Xen-devel] Is: axe read_tscp pvops call. Was: Re: [RFC] ACPI S3
and Xen (suprisingly
small\!).
On 10/18/2012 08:22 AM, Dan Magenheimer wrote:
It's a bit more complicated than that. The problem is that if
any patch is ever
On Thu, Oct 18, 2012 at 08:56:40AM -0700, Dan Magenheimer wrote:
I agree the whole idea of paravirtualization is a hack, but it is a
hack to workaround some poor architectural design decisions many years
ago by Intel processor designers who should have known better. Go yell
at them.
Worse,
On 17/10/12 17:54, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 17, 2012 at 09:50:11AM -0700, H. Peter Anvin wrote:
On 10/17/2012 09:10 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
Note:
On 10/18/2012 08:56 AM, Dan Magenheimer wrote:
Do you notice that the document you just claimed doesn't even exist at
this point, never mind being somehow enforced? In other word, there is
ABSOLUTELY NO WAY a mainline kernel developer can have any idea what
amount of violence Xen does to the
On Thu, 18 Oct 2012, Borislav Petkov wrote:
On Thu, Oct 18, 2012 at 08:56:40AM -0700, Dan Magenheimer wrote:
I agree the whole idea of paravirtualization is a hack, but it is a
hack to workaround some poor architectural design decisions many years
ago by Intel processor designers who should
On 10/18/2012 09:44 AM, Stefano Stabellini wrote:
I know that it is obvious but it is worth stating it in clear letters:
these are Dan's personal opinions and by no means represent the position
of the Xen community as a whole on this topic.
I, for one, have no idea what he is talking about.
As for 'perf', since Xen already provides a virtual PMU for HVM guests
It's not clear why we would spend the effort to implement another
mechanism for PV guests (instead of using the virtual PMU from a PVH guest).
Would that allow one to evaluate the performance/bottlenecks that the
hypervisor
On 18/10/12 18:42, Konrad Rzeszutek Wilk wrote:
As for 'perf', since Xen already provides a virtual PMU for HVM guests
It's not clear why we would spend the effort to implement another
mechanism for PV guests (instead of using the virtual PMU from a PVH guest).
Would that allow one to
I'm not sure it matters, but I'm testing against a changeset about a week old:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1c4a5b37b55c56e49135e65728137f54288d1fe6
Plus patches specific to XenClient Enterprise.
On Wed, Oct 17, 2012 at 1:43 PM, Konrad Rzeszutek Wilk
wrote:
> On Wed, Oct
On Wed, Oct 17, 2012 at 01:46:09PM -0400, Ben Guthro wrote:
> On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
> wrote:
> [...]
>
> > The end result is this is a nice set of patches where there is only
> > _one_ change in the x86 code (and it is just more of dealing with
> > error case) -
On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
wrote:
[...]
> The end result is this is a nice set of patches where there is only
> _one_ change in the x86 code (and it is just more of dealing with
> error case) - and the rest are all done in Xen side.
I'm sorry to report that this
On 10/17/2012 09:54 AM, Konrad Rzeszutek Wilk wrote:
Could you do an audit for other pvops calls that have no users? If
the *only* user is lguest, we should talk about it, too...
I can do that - but I don't want to be hasty here. There is a bit of
danger here - for example the read_pmc (or
On Wed, Oct 17, 2012 at 09:50:11AM -0700, H. Peter Anvin wrote:
> On 10/17/2012 09:10 AM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
> >>On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> >>>
> >>>Note: These are the other patches that went
On 10/17/2012 09:39 AM, Konrad Rzeszutek Wilk wrote:
which implies that it since it is a vDSO area it cannot do paravirt
calls anyhow.
Obviously. The vdso is *user space*.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Wed, Oct 17, 2012 at 12:10:36PM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
> > On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> > >
> > >Note: These are the other patches that went in 3.7-rc1:
> > >xen/bootup: allow
On 10/17/2012 09:10 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
Note: These are the other patches that went in 3.7-rc1:
xen/bootup: allow {read|write}_cr8 pvops call
On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
> On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
> >
> >Note: These are the other patches that went in 3.7-rc1:
> >xen/bootup: allow {read|write}_cr8 pvops call
> >[https://lkml.org/lkml/2012/10/10/339]
> >xen/bootup: allow
On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
Note: These are the other patches that went in 3.7-rc1:
xen/bootup: allow {read|write}_cr8 pvops call
[https://lkml.org/lkml/2012/10/10/339]
xen/bootup: allow read_tscp call for Xen PV guests.
[https://lkml.org/lkml/2012/10/10/340]
So
>From Konrad Rzeszutek Wilk # This line is ignored.
From: Konrad Rzeszutek Wilk
Subject: [RFC] ACPI S3 and Xen (surprisingly small\!).
In-Reply-To:
Hey,
Way back at the LinuxPlumbers 2012 I chatted with Len about the issue
with Xen and Linux not working very well when suspending. We did a bit
From Konrad Rzeszutek Wilk konrad.w...@oracle.com # This line is ignored.
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Subject: [RFC] ACPI S3 and Xen (surprisingly small\!).
In-Reply-To:
Hey,
Way back at the LinuxPlumbers 2012 I chatted with Len about the issue
with Xen and Linux not
On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
Note: These are the other patches that went in 3.7-rc1:
xen/bootup: allow {read|write}_cr8 pvops call
[https://lkml.org/lkml/2012/10/10/339]
xen/bootup: allow read_tscp call for Xen PV guests.
[https://lkml.org/lkml/2012/10/10/340]
So
On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
Note: These are the other patches that went in 3.7-rc1:
xen/bootup: allow {read|write}_cr8 pvops call
[https://lkml.org/lkml/2012/10/10/339]
xen/bootup: allow read_tscp call
On 10/17/2012 09:10 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
Note: These are the other patches that went in 3.7-rc1:
xen/bootup: allow {read|write}_cr8 pvops call
On Wed, Oct 17, 2012 at 12:10:36PM -0400, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
Note: These are the other patches that went in 3.7-rc1:
xen/bootup: allow {read|write}_cr8 pvops
On 10/17/2012 09:39 AM, Konrad Rzeszutek Wilk wrote:
which implies that it since it is a vDSO area it cannot do paravirt
calls anyhow.
Obviously. The vdso is *user space*.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Wed, Oct 17, 2012 at 09:50:11AM -0700, H. Peter Anvin wrote:
On 10/17/2012 09:10 AM, Konrad Rzeszutek Wilk wrote:
On Wed, Oct 17, 2012 at 09:03:12AM -0700, H. Peter Anvin wrote:
On 10/17/2012 06:49 AM, Konrad Rzeszutek Wilk wrote:
Note: These are the other patches that went in 3.7-rc1:
On 10/17/2012 09:54 AM, Konrad Rzeszutek Wilk wrote:
Could you do an audit for other pvops calls that have no users? If
the *only* user is lguest, we should talk about it, too...
I can do that - but I don't want to be hasty here. There is a bit of
danger here - for example the read_pmc (or
On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
[...]
The end result is this is a nice set of patches where there is only
_one_ change in the x86 code (and it is just more of dealing with
error case) - and the rest are all done in Xen side.
I'm sorry to
On Wed, Oct 17, 2012 at 01:46:09PM -0400, Ben Guthro wrote:
On Wed, Oct 17, 2012 at 9:49 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
[...]
The end result is this is a nice set of patches where there is only
_one_ change in the x86 code (and it is just more of dealing with
I'm not sure it matters, but I'm testing against a changeset about a week old:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=1c4a5b37b55c56e49135e65728137f54288d1fe6
Plus patches specific to XenClient Enterprise.
On Wed, Oct 17, 2012 at 1:43 PM, Konrad Rzeszutek Wilk
50 matches
Mail list logo
