PFA the diff between v2 and v3 for your convenience
On 12/12/18 11:49 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the ABI for the two halves of a para-virtualized
camera driver which extends Xen's reach multimedia capabilities even
farther enabling it for video con
On 12/13/18 5:48 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 12:17:54PM +0200, Oleksandr Andrushchenko wrote:
Daniel, could you please comment?
Cross-revieweing someone else's stuff would scale better,
fair enough
I don't think
I'll get around to anything before next year.
I put you
flight 131285 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131285/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 131172
test-armhf-armhf-
On Thu, Dec 13, 2018 at 11:37:37PM +0100, Paolo Bonzini wrote:
> Most files that have TABs only contain a handful of them. Change
> them to spaces so that we don't confuse people.
>
> disas, standard-headers, linux-headers and libdecnumber are imported
> from other projects and probably should be
PVRDTSCP is believed-unused, and its implementation has adverse consequences
on unrelated functionality in the hypervisor. As a result, support has been
removed.
Modify libxl to provide a slightly more helpful error message if it encounters
PVRDTSCP being selected. While adjusting TSC handling,
On Thu, Dec 13, 2018 at 11:37:37PM +0100, Paolo Bonzini wrote:
> Most files that have TABs only contain a handful of them. Change
> them to spaces so that we don't confuse people.
>
> disas, standard-headers, linux-headers and libdecnumber are imported
> from other projects and probably should be
On 12/13/18 4:37 PM, Paolo Bonzini wrote:
> Most files that have TABs only contain a handful of them. Change
> them to spaces so that we don't confuse people.
Acked-by: Richard Henderson
r~
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Most files that have TABs only contain a handful of them. Change
them to spaces so that we don't confuse people.
disas, standard-headers, linux-headers and libdecnumber are imported
from other projects and probably should be exempted from the check.
Outside those, after this patch the following f
On Thu, 13 Dec 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 12/12/18 11:53 PM, Stefano Stabellini wrote:
> > On Wed, 12 Dec 2018, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 11/12/2018 18:46, Stefano Stabellini wrote:
> > > > cplen is unsigned, thus, it can never be < 0. Use a signed i
The existing __get_instruction_length_from_list() has a single user
which uses the list functionality. That user however should be looking
specifically for INVD or WBINVD, as reported by the vmexit exit reason.
Modify svm_vmexit_do_invalidate_cache() to ask for the correct
instruction, and drop a
For both VT-x and SVM, the RDTSCP intercept will trigger if the pipeline
supports the instruction, but the guest may have not have rdtscp in its
featureset. Bring the vmexit handlers in line with the main emulator
behaviour by optionally handing back #UD.
Next on the AMD side, if RDTSCP actually
Sadly, a lone:
(XEN) emulate.c:156:d2v0 svm_get_insn_len: Mismatch between expected and
actual instruction: eip = f804564139c0
on the console is of no use trying to identify what went wrong. Dump as much
state as we can to help identify what went wrong.
Reported-by: Paul Durrant
Signed-
Updates in v2:
* Rework svm_get_insn_len() to be more simple.
* Drop anonymous union which will surely fail to compile on RHEL 6.x vintage
compilers.
* Rebase other changes
Andrew Cooper (3):
x86/svm: Simplify svm_get_insn_len()
x86/svm: Improve diagnostics when svm_get_insn_len() fa
flight 131263 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131263/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs.
131190
test-amd64-i38
On 12/13/18 3:13 PM, Andrii Anisov wrote:
Hello All,
OK, I've discovered a mechanism of the issue.
It is because of `d->max_pages = ~0U;` in a `construct_dom0()`.
When I do vcpu-pin, libxl updates memory nodes in xenstore for Dom0.
Then kernel watch sees those changes and trying to set new tar
Hi,
On 12/12/18 11:56 PM, Stefano Stabellini wrote:
On Wed, 12 Dec 2018, Julien Grall wrote:
On 11/12/2018 22:23, Stefano Stabellini wrote:
On Tue, 11 Dec 2018, Julien Grall wrote:
Furthermore, you are forwarding unsanitized values to the firmware. For
instance, what would happen if the numbe
Hi Stefano,
On 12/12/18 11:57 PM, Stefano Stabellini wrote:
On Tue, 11 Dec 2018, Julien Grall wrote:
Hi,
On 03/12/2018 21:03, Stefano Stabellini wrote:
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce data structs to implement basic access controls.
Introduce the following thre
>>> On 13.12.18 at 16:34, wrote:
> On Thu, Dec 13, 2018 at 07:52:16AM -0700, Jan Beulich wrote:
>> >>> On 13.12.18 at 15:14, wrote:
>> > On Thu, Dec 13, 2018 at 05:51:51AM -0700, Jan Beulich wrote:
>> >> >>> On 13.12.18 at 12:39, wrote:
>> >> > Well, Just keeping correct order between each domai
Hi Stefano,
On 12/12/18 11:55 PM, Stefano Stabellini wrote:
On Wed, 12 Dec 2018, Julien Grall wrote:
Hi Stefano,
On 11/12/2018 19:22, Stefano Stabellini wrote:
On Tue, 11 Dec 2018, Julien Grall wrote:
Hi,
On 03/12/2018 21:03, Stefano Stabellini wrote:
What is the plan there?
The plan is t
On Thu, Dec 13, 2018 at 12:17:54PM +0200, Oleksandr Andrushchenko wrote:
> Daniel, could you please comment?
Cross-revieweing someone else's stuff would scale better, I don't think
I'll get around to anything before next year.
-Daniel
>
> Thank you
>
> On 11/27/18 12:32 PM, Oleksandr Andrushche
On Thu, Dec 13, 2018 at 07:52:16AM -0700, Jan Beulich wrote:
> >>> On 13.12.18 at 15:14, wrote:
> > On Thu, Dec 13, 2018 at 05:51:51AM -0700, Jan Beulich wrote:
> >> >>> On 13.12.18 at 12:39, wrote:
> >> > Well, Just keeping correct order between each domain locks should be
> >> > enough?
> >> >
Jason Andryuk writes:
>> So if I understand correctly, the problem is that PCI passthrough
>> doesn't work with stubdomains, unless qemu is patched?
>
> Hi, Chris.
>
> I pulled in the QEMU patch because I found that my Intel wired
> ethernet device didn't work without it. I believe my Intel wire
On 12/13/18 4:58 PM, Jan Beulich wrote:
On 13.12.18 at 14:18, wrote:
>> So, long story short, on VMX we first send out the vm_event, while
>> processing it an interrupt / exception may become pending, before
>> resuming the VCPU that has sent out the vm_event there's a Xen function
>> that pi
Am 13.12.2018 um 13:44 hat Paul Durrant geschrieben:
> > Essentially, what I'm wondering is whether we have anything that could
> > be treated more or less like another monitor besides QMP and HMP, which
> > would internally work similar to HMP, i.e. map (almost) everything to
> > QMP commands.
>
>>> On 13.12.18 at 14:18, wrote:
> So, long story short, on VMX we first send out the vm_event, while
> processing it an interrupt / exception may become pending, before
> resuming the VCPU that has sent out the vm_event there's a Xen function
> that picks up the pending interrupt and schedules it
>>> On 13.12.18 at 15:14, wrote:
> On Thu, Dec 13, 2018 at 05:51:51AM -0700, Jan Beulich wrote:
>> >>> On 13.12.18 at 12:39, wrote:
>> > Well, Just keeping correct order between each domain locks should be
>> > enough?
>> >
>> > Ie: exactly the same that Xen currently does but on a per-domain
>>
flight 131293 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131293/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 13.12.18 at 15:20, wrote:
> On Thu, Dec 13, 2018 at 03:17:05AM -0700, Jan Beulich wrote:
>> >>> On 13.12.18 at 10:14, wrote:
>> > On Thu, Dec 13, 2018 at 12:45:07AM -0700, Jan Beulich wrote:
>> >> >>> On 12.12.18 at 18:05, wrote:
>> >> > On Wed, Dec 12, 2018 at 09:15:09AM -0700, Jan Beuli
>>> On 13.12.18 at 14:25, wrote:
> The question is, how much drift can be tolerated even without my patch.
This depends on what a system is used for. A few seconds off may
be fine for one purpose, but a significant problem for another.
Similarly a sudden (however small) change to the TSC tick rat
>>> On 01.12.18 at 02:33, wrote:
> --- a/xen/common/argo.c
> +++ b/xen/common/argo.c
> @@ -1656,6 +1656,46 @@ argo_sendv(struct domain *src_d, const argo_addr_t
> *src_addr,
> return ( ret < 0 ) ? ret : len;
> }
>
> +static void
> +argo_get_config(struct domain *d, argo_get_config_t *get_
flight 131283 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131283/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
>>> On 01.12.18 at 02:33, wrote:
> so that the guest may re-register the rings on resume with current mappings.
Is this something guests really need help with, rather than managing
it on their own? What does "current mappings" here mean, i.e. why
do rings need re-registration in the first place?
On Thu, Dec 13, 2018 at 03:17:05AM -0700, Jan Beulich wrote:
> >>> On 13.12.18 at 10:14, wrote:
> > On Thu, Dec 13, 2018 at 12:45:07AM -0700, Jan Beulich wrote:
> >> >>> On 12.12.18 at 18:05, wrote:
> >> > On Wed, Dec 12, 2018 at 09:15:09AM -0700, Jan Beulich wrote:
> >> >> The MMIO side of thing
>>> On 01.12.18 at 02:33, wrote:
> * x86 PV domains are notified via event channel.
>
> PV guests are known to have the event channel software present in the guest
> kernel, so it is fine to depend on and use it.
>
> * x86 HVM domains and all ARM domains are notified via VIRQ.
>
> The intent is
On Thu, Dec 13, 2018 at 05:51:51AM -0700, Jan Beulich wrote:
> >>> On 13.12.18 at 12:39, wrote:
> > On Wed, Dec 12, 2018 at 09:07:14AM -0700, Jan Beulich wrote:
> >> >>> On 12.12.18 at 15:54, wrote:
> >> > @@ -488,6 +490,16 @@ static int paging_log_dirty_op(struct domain *d,
> >> >
>>> On 01.12.18 at 02:33, wrote:
> To be used by Argo for delivery of notifications to some guests.
Better not to make this a separate patch: By folding it into where it's
needed it is easier for everyone to judge whether the exposure is
indeed necessary, and it also eliminates the risk of the se
Hello All,
OK, I've discovered a mechanism of the issue.
It is because of `d->max_pages = ~0U;` in a `construct_dom0()`.
When I do vcpu-pin, libxl updates memory nodes in xenstore for Dom0. Then
kernel watch sees those changes and trying to set new target for ballon, but
the target becomes ext
>>> On 01.12.18 at 02:33, wrote:
> This is out of an abundance of caution, since this is a very basic hash
> function, chosen more for its bucket distribution properties to cluster
> related
> rings rather than for cryptographic strength or any uniformness of output,
> and it operates upon values
>>> On 01.12.18 at 02:32, wrote:
> Very basic implementation: a fixed limit of 128.
Such restrictions to limit resource use would better be implemented
right away for code that can be used (in a limited way) already with
just the initial parts of the series applied.
Jan
__
>>> On 01.12.18 at 02:32, wrote:
> +static uint32_t
> +argo_ringbuf_payload_space(struct domain *d, struct argo_ring_info
> *ring_info)
> +{
> +argo_ring_t ring;
> +int32_t ret;
> +
> +ASSERT(spin_is_locked(&ring_info->lock));
> +
> +ring.len = ring_info->len;
> +if ( !ring.le
Am Thu, 13 Dec 2018 03:41:44 -0700
schrieb "Jan Beulich" :
> And further argumentation that everyone is using NTP anyway
> doesn't make it any better, when it's no-where written down that
> Xen is unusable with NTP running in all guests (I'm exaggerating
> here just to get the point over). Don't f
On 12/13/18 2:39 PM, Julien Grall wrote:
> Hi,
>
> On 12/13/18 12:15 PM, Razvan Cojocaru wrote:
>> On 12/13/18 2:04 PM, Julien Grall wrote:
>>> Hi,
>>>
>>> On 12/13/18 8:03 AM, Razvan Cojocaru wrote:
On 12/13/18 8:54 AM, Tian, Kevin wrote:
>> From: Razvan Cojocaru [mailto:rcojoc...@bitdef
>>> On 01.12.18 at 02:32, wrote:
> --- /dev/null
> +++ b/xen/include/public/argo.h
> @@ -0,0 +1,55 @@
> +/**
> + * Argo : Hypervisor-Mediated data eXchange
> + *
> + * Derived from v4v, the version 2 of v2v.
> + *
> + * Co
On 12/12/18 21:39, Borislav Petkov wrote:
> On Tue, Dec 11, 2018 at 11:29:21AM -0800, Maran Wilson wrote:
>> Is your question about what options you need to provide to Qemu? Or is your
>> question about the SW implementation choices?
>>
>> Assuming the former...
> Yeah, that's what I wanted to know
On 12/12/18 19:09, Maran Wilson wrote:
> On 12/6/2018 1:21 PM, Paolo Bonzini wrote:
>> On 06/12/18 07:02, Maran Wilson wrote:
>>> For certain applications it is desirable to rapidly boot a KVM virtual
>>> machine. In cases where legacy hardware and software support within the
>>> guest is not neede
On Thu, Dec 13, 2018 at 12:54:52AM -0700, Jan Beulich wrote:
On 13.12.18 at 04:46, wrote:
>> On Wed, Dec 12, 2018 at 08:21:39AM -0700, Jan Beulich wrote:
>> On 12.12.18 at 16:18, wrote:
On Wed, Dec 12, 2018 at 01:51:01AM -0700, Jan Beulich wrote:
On 12.12.18 at 08:06, wrot
I think there are two issues:
1) VIRQ vs some other sort of event channel
For PV guests we originally chose a VIRQ in order to have a well known
number against which the kernel driver could bind, so that it wasn't
dependent on any of the other interdomain communication systems (such
a
Hi Liam,
in order to support PVH also with SeaBIOS, I'm going to work on a new
option rom (like linuxboot/multiboot) that can be used in this case.
I'll keep you updated on it!
Cheers,
Stefano
On Wed, Dec 5, 2018 at 11:38 PM Liam Merwick wrote:
>
> These changes (along with corresponding qboot a
On Tue, Dec 11, 2018 at 7:35 PM Maran Wilson wrote:
>
> On 12/11/2018 9:11 AM, Stefano Garzarella wrote:
> > Hi Liam,
> > in order to support PVH also with SeaBIOS, I'm going to work on a new
> > option rom (like linuxboot/multiboot) that can be used in this case.
>
> That is awesome. Yes, please
>>> On 13.12.18 at 12:39, wrote:
> On Wed, Dec 12, 2018 at 09:07:14AM -0700, Jan Beulich wrote:
>> >>> On 12.12.18 at 15:54, wrote:
>> > @@ -488,6 +490,16 @@ static int paging_log_dirty_op(struct domain *d,
>> > bytes = (unsigned int)((sc->pages - pages + 7) >> 3);
>> >
> -Original Message-
> From: Kevin Wolf [mailto:kw...@redhat.com]
> Sent: 13 December 2018 11:52
> To: Paul Durrant
> Cc: qemu-de...@nongnu.org; qemu-bl...@nongnu.org; xen-
> de...@lists.xenproject.org; Max Reitz ; Stefano
> Stabellini
> Subject: Re: [PATCH v4 16/18] xen: automatically cr
Hi,
On 12/13/18 12:15 PM, Razvan Cojocaru wrote:
On 12/13/18 2:04 PM, Julien Grall wrote:
Hi,
On 12/13/18 8:03 AM, Razvan Cojocaru wrote:
On 12/13/18 8:54 AM, Tian, Kevin wrote:
From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
Sent: Tuesday, December 11, 2018 8:33 PM
In any case, I
On Wed, Dec 12, 2018 at 11:16:23AM +, Paul Durrant wrote:
> This series is a re-base of Tim's v2 series [1] on top of my series [2].
>
> [1] https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg00243.html
> [2] https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg02271.html
For the se
On 12/13/18 2:04 PM, Julien Grall wrote:
> Hi,
>
> On 12/13/18 8:03 AM, Razvan Cojocaru wrote:
>> On 12/13/18 8:54 AM, Tian, Kevin wrote:
From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
Sent: Tuesday, December 11, 2018 8:33 PM
> In any case, I think you want to rename t
On Wed, 12 Dec 2018 16:00:06 +0400
Marc-André Lureau wrote:
> Hi
> On Mon, Dec 10, 2018 at 8:55 PM Igor Mammedov wrote:
> >
> > On Mon, 10 Dec 2018 17:45:22 +0100
> > Igor Mammedov wrote:
> >
> > > On Tue, 4 Dec 2018 18:20:11 +0400
> > > Marc-André Lureau wrote:
> > >
> > > > Instead of r
Hi,
On 12/13/18 8:03 AM, Razvan Cojocaru wrote:
On 12/13/18 8:54 AM, Tian, Kevin wrote:
From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
Sent: Tuesday, December 11, 2018 8:33 PM
In any case, I think you want to rename the function and/or document
more that expected behavior.
You're
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Anthony PERARD
> Sent: 13 December 2018 11:34
> To: Olaf Hering
> Cc: Kevin Wolf ; Stefano Stabellini
> ; open list:Block layer core bl...@nongnu.org>; qemu-de...@nongnu.org; Max Reitz ;
Am 11.12.2018 um 16:57 hat Paul Durrant geschrieben:
> This patch adds a creator function for XenBlockDevice-s so that they can
> be created automatically when the Xen toolstack instantiates a new
> PV backend. When the XenBlockDevice is created this way it is also
> necessary to create a drive whi
On Wed, Dec 12, 2018 at 09:07:14AM -0700, Jan Beulich wrote:
> >>> On 12.12.18 at 15:54, wrote:
> > Fix this by releasing the target paging lock before attempting to
> > perform the copy of the dirty bitmap, and then forcing a restart of
> > the whole process in case there have been changes to the
On Tue, Dec 11, 2018 at 05:02:24PM +0100, Olaf Hering wrote:
> There are some code paths that clobber ioreq->buf, which leads to a huge
> memory leak after a few hours of runtime. One code path is
> qemu_aio_complete, which might be called recursive. Another one is
I think it's s/recursive/recursi
Hi,
Ian, we have those XC_WANT_COMPAT_* #defines to allow consumers of Xen
libs be able to use old interfaces. Do you think it's a good idea to
have this consumers (QEMU here) #undef the flag when it has implemented
the newer interface?
I guess the issue we have here is that when libxc interface
Am Thu, 13 Dec 2018 03:41:44 -0700
schrieb "Jan Beulich" :
> In a second step, let's consider what impact errors in calibration have.
> Between two systems with exactly the same hardware crystal
> frequency there of course is going to be some drift. The problem
> though is - between the two calibr
Hi Stefano,
On 12/12/18 11:53 PM, Stefano Stabellini wrote:
On Wed, 12 Dec 2018, Julien Grall wrote:
Hi Stefano,
On 11/12/2018 18:46, Stefano Stabellini wrote:
cplen is unsigned, thus, it can never be < 0. Use a signed integer local
variable instead.
The current code checks > 0. Looking at
>>> On 13.12.18 at 11:22, wrote:
> For my own part, I see no reason why not clipping end should not work
> when updating the ranges only (as long as start continues to be <=
> unclipped_end).
>
> Would that modification + testing of it help this series continue?
I think so, at least as far as I'
>>> On 13.12.18 at 10:04, wrote:
> Am Thu, 13 Dec 2018 01:45:39 -0700
> schrieb "Jan Beulich" :
>
>> >>> On 13.12.18 at 09:18, wrote:
>> > Am Wed, 12 Dec 2018 09:39:25 -0700
>> > schrieb "Jan Beulich" :
>> >
>> >> >>> On 12.12.18 at 16:20, wrote:
>> >> > If a domU uses TSC as clocksour
On 12/5/18 6:30 PM, Jan Beulich wrote:
On 05.12.18 at 10:18, wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -1002,30 +1002,43 @@ int p2m_change_type_one(struct domain *d, unsigned
>> long gfn_l,
>> return rc;
>> }
>>
>> -/* Modify the p2m type of a range o
Daniel, could you please comment?
Thank you
On 11/27/18 12:32 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it possible that
the backend sees only partial content of th
>>> On 13.12.18 at 10:14, wrote:
> On Thu, Dec 13, 2018 at 12:45:07AM -0700, Jan Beulich wrote:
>> >>> On 12.12.18 at 18:05, wrote:
>> > On Wed, Dec 12, 2018 at 09:15:09AM -0700, Jan Beulich wrote:
>> >> The MMIO side of things of course still remains unclear.
>> >
>> > Right, for the MMIO and t
bump
On 12/5/18 10:20 AM, Oleksandr Andrushchenko wrote:
Hello, Daniel!
Could you please ack/nack the patch, so either we can merge the
series or I can address your comments if any
Thank you,
Oleksandr
On 11/30/18 9:42 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Use
flight 131257 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131257/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 129676
Tests which ar
On Thu, Dec 13, 2018 at 12:45:07AM -0700, Jan Beulich wrote:
> >>> On 12.12.18 at 18:05, wrote:
> > On Wed, Dec 12, 2018 at 09:15:09AM -0700, Jan Beulich wrote:
> >> The MMIO side of things of course still remains unclear.
> >
> > Right, for the MMIO and the handling of grant and foreign mappings
Am Thu, 13 Dec 2018 01:45:39 -0700
schrieb "Jan Beulich" :
> >>> On 13.12.18 at 09:18, wrote:
> > Am Wed, 12 Dec 2018 09:39:25 -0700
> > schrieb "Jan Beulich" :
> >
> >> >>> On 12.12.18 at 16:20, wrote:
> >> > If a domU uses TSC as clocksoure it also must run NTP in some way to
> >> > a
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Thursday, December 13, 2018 4:40 PM
>
> On Thu, Dec 13, 2018 at 02:44:00AM +, Tian, Kevin wrote:
> > btw can you also capture ISR/IRR/PPR right before local_irq_enable()?
> > though I didn't see a reason why code in-between may impa
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, December 13, 2018 4:37 PM
>
> >>> On 13.12.18 at 02:28, wrote:
> > btw I checked your original mail:
> >
> > (XEN)[] mwait-idle.c#mwait_idle+0x2a5/0x381
> > xen/arch/x86/cpu/mwait-idle.c:802
> >
> >788 if (cpu_i
On Thu, Dec 13, 2018 at 01:28:23AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné [mailto:roger@citrix.com]
> > Sent: Wednesday, December 12, 2018 8:18 PM
> >
> > On Wed, Dec 12, 2018 at 11:48:52AM +, Tian, Kevin wrote:
> > > > From: Roger Pau Monné [mailto:roger@citrix.com]
> > >
>>> On 13.12.18 at 09:18, wrote:
> Am Wed, 12 Dec 2018 09:39:25 -0700
> schrieb "Jan Beulich" :
>
>> >>> On 12.12.18 at 16:20, wrote:
>> > If a domU uses TSC as clocksoure it also must run NTP in some way to
>> > avoid the potential drift what will most likely happen, independent of
>> > any m
On Thu, Dec 13, 2018 at 02:44:00AM +, Tian, Kevin wrote:
> btw can you also capture ISR/IRR/PPR right before local_irq_enable()?
> though I didn't see a reason why code in-between may impact those
> bits, it doesn't hurt to capture the context right before interrupt is
> raised. :-)
I've done
>>> On 13.12.18 at 02:28, wrote:
> btw I checked your original mail:
>
> (XEN)[] mwait-idle.c#mwait_idle+0x2a5/0x381
> xen/arch/x86/cpu/mwait-idle.c:802
>
>788if (cpu_is_haltable(cpu))
>789mwait_idle_with_hints(eax,
> MWAIT_ECX_INTERRUPT_BREAK
>>> On 12.12.18 at 22:41, wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-pair
> testid xen-boot/src_host
>
> Tree: linux
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
>
Am Wed, 12 Dec 2018 09:39:25 -0700
schrieb "Jan Beulich" :
> >>> On 12.12.18 at 16:20, wrote:
> > If a domU uses TSC as clocksoure it also must run NTP in some way to
> > avoid the potential drift what will most likely happen, independent of
> > any migration.
> Which drift? While anyone's we
On 12/13/18 8:54 AM, Tian, Kevin wrote:
>> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
>> Sent: Tuesday, December 11, 2018 8:33 PM
>>
>>> In any case, I think you want to rename the function and/or document
>>> more that expected behavior.
>>
>> You're right, I should probably rename t
81 matches
Mail list logo
