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
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
> 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
>>> 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
> 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
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
> >> >
>>> 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
>
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
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 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,
>
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
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
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
>>> 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
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
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
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
>>> 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
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
> -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 ;
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
>>> 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
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
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
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
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
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
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
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
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
>>> 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.
> + *
> + *
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
>>> 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: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
>>> 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
> -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
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 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
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,
>>> 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(_info->lock));
> +
> +ring.len = ring_info->len;
> +if ( !ring.len )
>>> 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
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,
>>> 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);
>> >
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
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
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:
> * 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
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
>>> 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 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
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
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:
> --- 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
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
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 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
>>> 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
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
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?
> >> >
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
>>> 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
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
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
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
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
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
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
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()
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
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
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
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
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
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
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,
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
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
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
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
80 matches
Mail list logo
