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, b
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. Ev
> 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 k
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
> 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
hypervis
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 a
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.
>
> Wor
> 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 th
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 ins
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 is lguest,
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) - a
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 serie
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 re
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 i
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 {read|write}_cr
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
[https://lkml.org/lkm
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
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 WTF
>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
25 matches
Mail list logo
