On Fri, Oct 13, 2017 at 04:10:31PM +0530, Bhupinder Thakur wrote:
> This patch fixes the issue observed when pl011 patches were tested on
> the junos hardware by Andre/Julien. It was observed that when large
> output is generated such as on running 'find /', output was getting
> truncated intermitt
>>> On 13.10.17 at 15:03, wrote:
> On 13/10/17 13:32, Jan Beulich wrote:
> On 13.10.17 at 14:19, wrote:
>>> On 13/10/17 13:08, Jan Beulich wrote:
>>> On 13.10.17 at 12:44, wrote:
> In libxl__device_vuart_add vuart_gfn is getting stored as a hex value:
>
>> flexarray_append(ro
On 10/13/2017 04:40 AM, Yi Sun wrote:
This patch renames PSR sysctl/domctl interfaces and related xsm policy to
make them be general for all resource allocation features but not only
for CAT. Then, we can resuse the interfaces for all allocation features.
Basically, it changes 'psr_cat_op' to 'p
On Fri, Oct 13, 2017 at 6:17 AM, Jan Beulich wrote:
On 13.10.17 at 12:36, wrote:
>> On 13.10.2017 13:29, Jan Beulich wrote:
+__set_bit(index + sizeof(struct monitor_msr_bitmap), bitmap);
>>>
>>> I think you miss "* 8" here - a bit position plus sizeof() doesn't
>>> produce any u
Hi Jan,
On 13/10/17 15:03, Jan Beulich wrote:
On 13.10.17 at 15:03, wrote:
On 13/10/17 13:32, Jan Beulich wrote:
On 13.10.17 at 14:19, wrote:
On 13/10/17 13:08, Jan Beulich wrote:
On 13.10.17 at 12:44, wrote:
In libxl__device_vuart_add vuart_gfn is getting stored as a hex value:
flexar
>>> On 13.10.17 at 16:35, wrote:
> Hi Jan,
>
> On 13/10/17 15:03, Jan Beulich wrote:
> On 13.10.17 at 15:03, wrote:
>>> On 13/10/17 13:32, Jan Beulich wrote:
>>> On 13.10.17 at 14:19, wrote:
> On 13/10/17 13:08, Jan Beulich wrote:
> On 13.10.17 at 12:44, wrote:
>>> In l
On 13/10/17 13:35, Sergey Dyasli wrote:
> @@ -210,6 +375,255 @@ struct msr_domain_policy
> bool available; /* This MSR is non-architectural */
> bool cpuid_faulting;
> } plaform_info;
> +
> +/* 0x0480 MSR_IA32_VMX_BASIC */
> +struct {
> +bool available;
On 13/10/17 13:35, Sergey Dyasli wrote:
> Availability of some MSRs depends on certain CPUID bits. Add function
> recalculate_domain_msr_policy() which updates availability of per-domain
> MSRs based on current domain's CPUID policy. This function is called
> when CPUID policy is changed from a too
On 13/10/17 13:35, Sergey Dyasli wrote:
> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
> index a22e3dfaf2..2527fdd1d1 100644
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -426,6 +426,13 @@ int init_vcpu_msr_policy(struct vcpu *v)
> return 0;
> }
>
> +#define vmx_guest_r
On 13/10/17 14:01, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH for-4.10] libxl: handle NULL in
> libxl__enum_from_string"):
>> I agree they shouldn't be called with NULL. We should guard against
>> error (here or the libxl_*_type_from_string) or annotate the input can't
>> be NULL.
> I mean,
>>> On 13.10.17 at 14:50, wrote:
> This patch adds the old value param and the onchangeonly option
> to the VM_EVENT_REASON_MOV_TO_MSR event.
>
> The param was added to the vm_event_mov_to_msr struct and to the
> hvm_monitor_msr function. Finally I've changed the bool_t param
> to a bool for the
>>> On 13.10.17 at 10:41, wrote:
> @@ -274,16 +280,18 @@ static enum psr_feat_type psr_type_to_feat_type(enum
> psr_type type)
> return feat_type;
> }
>
> -static bool psr_check_cbm(unsigned int cbm_len, unsigned long cbm)
> +/* Implementation of allocation features' functions. */
> +stat
On 10/13/17 2:40 AM, Jan Beulich wrote:
On 12.10.17 at 22:56, wrote:
>> On 12/10/2017 21:50, Doug Goldstein wrote:
>>> From: David Esler
>>>
>>> The send_chr function sends an entire C-string and not one character and
>>> doesn't necessarily just send it over the serial UART anymore so renam
On 13/10/17 17:07, Doug Goldstein wrote:
> On 10/13/17 2:40 AM, Jan Beulich wrote:
> On 12.10.17 at 22:56, wrote:
>>> On 12/10/2017 21:50, Doug Goldstein wrote:
From: David Esler
The send_chr function sends an entire C-string and not one character and
doesn't necessarily j
Andrew Cooper writes ("Re: [Xen-devel] [PATCH for-4.10] libxl: handle NULL in
libxl__enum_from_string"):
> On 13/10/17 14:01, Ian Jackson wrote:
> > Instead, what we have actually done so far, is annotate when a pointer
> > parameter *may* be NULL, and, in that case, what that means:
>
> This is
On Fri, Oct 13, 2017 at 9:50 AM, Jan Beulich wrote:
On 13.10.17 at 14:50, wrote:
>> This patch adds the old value param and the onchangeonly option
>> to the VM_EVENT_REASON_MOV_TO_MSR event.
>>
>> The param was added to the vm_event_mov_to_msr struct and to the
>> hvm_monitor_msr function.
Hi,
Sorry for the top-posting. Bhupinder, can you give a look?
Cheers,
On 13/10/17 16:06, Jan Beulich wrote:
On 13.10.17 at 16:35, wrote:
Hi Jan,
On 13/10/17 15:03, Jan Beulich wrote:
On 13.10.17 at 15:03, wrote:
On 13/10/17 13:32, Jan Beulich wrote:
On 13.10.17 at 14:19, wrote:
On 13
On 10/13/2017 07:26 PM, Tamas K Lengyel wrote:
> On Fri, Oct 13, 2017 at 9:50 AM, Jan Beulich wrote:
> On 13.10.17 at 14:50, wrote:
>>> This patch adds the old value param and the onchangeonly option
>>> to the VM_EVENT_REASON_MOV_TO_MSR event.
>>>
>>> The param was added to the vm_event_mov_
c/s 4d69b3495 "Introduce migration precopy policy" uses bogus reasoning to
justify passing precopy_stats by value.
Under no circumstances can the precopy callback ever be executing in a
separate address space.
Switch the callback to passing by pointer which is far more efficient, and
drop the typ
* Don't zero ctx->save.stats; it is already zeroed
* No need for x as it duplicates ctx->save.stats.iteration
* Defer setting dirty_count until the bitmap has been filled to match the
behaviour of XEN_DOMCTL_SHADOW_OP_CLEAN
* Drop spurious blank line
Signed-off-by: Andrew Cooper
---
CC: Ia
The x86 platform operations are fairly isolated, so we can
change them from using timespec to timespec64. I checked that
All the users and callers are safe, and there is only one
critical function that is broken beyond 2106:
pvclock_read_wallclock() uses a 32-bit number of seconds since
the epoch
Dear Community members,
I am pleased to announce that Stefano Stabellini has been nominated and
voted to become a new member of the Xen Project security team. The vote
was unanimous with all security team members voting in favour of
Stefano's membership.
Stefano has made significant contributions
On 10/13/2017 02:37 PM, Arnd Bergmann wrote:
> The x86 platform operations are fairly isolated, so we can
> change them from using timespec to timespec64. I checked that
> All the users and callers are safe, and there is only one
> critical function that is broken beyond 2106:
>
> pvclock_read_wall
flight 114420 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114420/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-2 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 114072
Regressions whi
On Fri, 13 Oct 2017, Jan Beulich wrote:
> >>> On 13.10.17 at 13:13, wrote:
> > To Jan, Andrew, Stefano and Anthony,
> >
> > what do you think about allowing QEMU to build the entire guest ACPI
> > and letting SeaBIOS to load it? ACPI builder code in hvmloader is
> > still there and just bypassed
flight 114422 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114422/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 114097
test-armhf-armh
flight 114423 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114423/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 7 xen-boot fail REGR. vs. 114263
Tests which did not succ
101 - 127 of 127 matches
Mail list logo
