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
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
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 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 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
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
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
* 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
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
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_
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 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.
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 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
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 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 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 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 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 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:
> @@ -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 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
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 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
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 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 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:00, wrote:
> On Vi, 2017-10-13 at 03:51 -0600, Jan Beulich wrote:
>> >
>> >
>> > +BUILD_BUG_ON(sizeof(struct
>> > xen_hvm_altp2m_set_mem_access_multi) <
>> > + sizeof(struct
>> > compat_hvm_altp2m_set_mem_access_multi));
>> What good does
flight 114409 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114409/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-amd 12 guest-start fail REGR. vs. 114042
test-amd64-amd64-
Windows tests consume quite a bit more disk space under /root.
Signed-off-by: Wei Liu
---
Osstest.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest.pm b/Osstest.pm
index a78728c..34b5b6d 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -94,7 +94,7 @@ our %c = qw(
H
Some of our Windows guests have more RAM now, and some of them have
big ISOs too. The guest memory ends up in /root as a save image, and
the ISO ends up there too.
Double the size of / to 20G. That will probably do for now and is
unlikely to break anything.
Signed-off-by: Ian Jackson
Reported-
pt_update_irq() is expected to return the vector number of periodic
timer interrupt, which should be set in vIRR of vlapic or in PIR.
Otherwise it would trigger the assertion in vmx_intr_assist(), please
seeing
https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg00915.html.
But it fai
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, who calls any libxl_*_from_string with s==NU
Hi,
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_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
Howeve
On Vi, 2017-10-13 at 03:51 -0600, Jan Beulich wrote:
> >
> >
> > +BUILD_BUG_ON(sizeof(struct
> > xen_hvm_altp2m_set_mem_access_multi) <
> > + sizeof(struct
> > compat_hvm_altp2m_set_mem_access_multi));
> What good does this do?
> Sorry, I don't understand how t
On Fri, Oct 13, 2017 at 01:46:57PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH for-4.10] libxl: handle NULL in
> libxl__enum_from_string"):
> > Discovered by Coverity.
>
> But. Surely it is very wrong
>
> > @@ -1017,7 +1017,7 @@ int libxl_get_max_nodes(libxl_ctx *ctx)
> > int libxl__en
flight 114460 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114460/
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
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 hvm_msr_write_intercept function.
Signed-off-
Wei Liu writes ("[PATCH for-4.10] libxl: handle NULL in
libxl__enum_from_string"):
> Discovered by Coverity.
But. Surely it is very wrong
> @@ -1017,7 +1017,7 @@ int libxl_get_max_nodes(libxl_ctx *ctx)
> int libxl__enum_from_string(const libxl_enum_string_table *t,
>
Add calculate_raw_vmx_policy() which fills Raw policy with H/W values
of VMX MSRs. Host policy will contain a copy of these values.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/msr.c | 77 ++
1 file changed, 77 insertions(+)
diff --git a/xen/
Currently, when nested virt is enabled, the set of L1 VMX features
is fixed and calculated by nvmx_msr_read_intercept() as an intersection
between the full set of Xen's supported L1 VMX features, the set of
actual H/W features and, for MSR_IA32_VMX_EPT_VPID_CAP, the set of
features that Xen uses.
The end goal of having VMX MSRs policy is to be able to manage
L1 VMX features. This patch series is the first part of this work.
There is no functional change to what L1 sees in VMX MSRs at this
point. But each domain will have a policy object which allows to
sensibly query what VMX features the d
Now that each domain has a correct view of VMX MSRs in it's per-domain
MSR policy, it's possible to handle guest's RD/WRMSR with the new
handlers. Do it and remove the old nvmx_msr_read_intercept() and
associated bits.
There is no functional change to what a guest sees in VMX MSRs.
Signed-off-by:
Raw policy contains the actual values from H/W MSRs. PLATFORM_INFO msr
needs to be read again because probe_intel_cpuid_faulting() records
the presence of X86_FEATURE_CPUID_FAULTING but not the presence of msr
itself (if cpuid faulting is not available).
Host policy might have certain features dis
New definitions provide a convenient way of accessing contents of
VMX MSRs: every bit value is accessible by its name and there is a
"raw" 64-bit msr value. Bit names match existing Xen's definitions
as close as possible.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/msr.c| 42 +
xe
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 toolstack.
Add recalculate_domain_vmx_msr_policy()
flight 114402 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114402/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken in 114321
test-armhf-armhf-xl-rtds
>>> 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_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
>>> However, xenstore reads this
>>> On 13.10.17 at 12:44, wrote:
> On Fri, Oct 13, 2017 at 08:59:29AM +, Jan Beulich wrote:
>> >>> On 13.10.17 at 10:49, wrote:
>> On 29.09.17 at 13:25, wrote:
>> >> nr_pages doesn't take into account holes or MMIO regions, and
>> >> underestimates the amount of memory needed for paging
>>> On 13.10.17 at 13:17, wrote:
> On Tue, Oct 10, 2017 at 11:35:26AM +, Roger Pau Monné wrote:
>> On Wed, Oct 04, 2017 at 08:34:13AM +, Jan Beulich wrote:
>> > >>> On 19.09.17 at 17:29, wrote:
>> > > +static void vpci_msi_enable(const struct pci_dev *pdev, struct vpci_msi
>> > > *msi,
>
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_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
>> However, xenstore reads this value as a decimal value and tries to ma
>>> 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 useful value.
>>
>> But what's worse - having read till th
>>> 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 in this case.
Well, if that can be made work in a n
>>> 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_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
>
> However, xenstore reads this value as a decimal value and tries to map the
> wrong address and fails.
Is th
Jan,
I had sent the mail an hour after I ran the scripts (had a meeting in between).
I will look into the issue with XSA 226
On commits c7783d9c26fc191862d9883da22387340b1fab18 &
d6aad635097d901b96df650e87f04687c9fb7bd2: I have to look into why these didn’t
get picked up.
Maybe there is a bug
On Fri, Oct 13, 2017 at 04:14:32PM +0530, Bhupinder Thakur wrote:
> In libxl__device_vuart_add vuart_gfn is getting stored as a hex value:
>
> > flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
>
> However, xenstore reads this value as a decimal value and tries to map the
Discovered by Coverity.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
---
tools/libxl/libxl_utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 507ee56c7c..9433693e72 100644
--- a/tools/libxl/libxl_utils.c
+++ b/to
On Tue, Oct 10, 2017 at 11:35:26AM +, Roger Pau Monné wrote:
> On Wed, Oct 04, 2017 at 08:34:13AM +, Jan Beulich wrote:
> > >>> On 19.09.17 at 17:29, wrote:
> > > +static void vpci_msi_enable(const struct pci_dev *pdev, struct vpci_msi
> > > *msi,
> > > +unsign
On 10/13/17 10:44 +0200, Igor Mammedov wrote:
> On Fri, 13 Oct 2017 15:53:26 +0800
> Haozhong Zhang wrote:
>
> > On 10/12/17 17:45 +0200, Paolo Bonzini wrote:
> > > On 12/10/2017 14:45, Haozhong Zhang wrote:
> > > > Basically, QEMU builds two ROMs for guest, /rom@etc/acpi/tables and
> > > > /ro
Implement support for restricting evtchn handles to a particular domain
on Linux by calling the IOCTL_EVTCHN_RESTRICT_DOMID ioctl (support added
in Linux v4.8).
Signed-off-by: Ross Lagerwall
---
tools/include/xen-sys/Linux/evtchn.h | 15 +++
tools/libs/evtchn/Makefile|
Signed-off-by: Ross Lagerwall
---
tools/Rules.mk| 2 +-
tools/libs/evtchn/Makefile| 4 ++--
tools/libs/evtchn/core.c | 13 +
tools/libs/evtchn/private.h | 3 +++
tools/libs/toolcore/include/xentoolcore.h |
On Fri, Oct 13, 2017 at 08:59:29AM +, Jan Beulich wrote:
> >>> On 13.10.17 at 10:49, wrote:
> On 29.09.17 at 13:25, wrote:
> >> nr_pages doesn't take into account holes or MMIO regions, and
> >> underestimates the amount of memory needed for paging. Be on the safe
> >> side and use max_p
In libxl__device_vuart_add vuart_gfn is getting stored as a hex value:
> flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
However, xenstore reads this value as a decimal value and tries to map the
wrong address and fails.
Introduced a new format string "PRIu_xen_pfn" whic
Ross Lagerwall writes ("Re: [PATCH 3/8] xen: defer call to xen_restrict until
just before os_setup_post"):
> This works for normally starting a VM but doesn't seem to work when
> resuming/migrating.
>
> Here is the order of selected operations when starting a VM normally:
> VNC server runni
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 intermittently due to OUT ring buffer getting full.
This issue was due to the fact
The early console output uses pl011_early_write() to write data. This
function waits for BUSY bit to get cleared before writing the next byte.
In the SBSA UART emulation logic, the BUSY bit was set as soon one
byte was written in the FIFO and it remained set until the FIFO was
emptied. This meant
>>> On 13.10.17 at 10:40, wrote:
> @@ -319,11 +340,13 @@ static bool cat_init_feature(const struct cpuid_leaf
> *regs,
> feat->cos_max = (feat->cos_max - 1) >> 1;
>
> /* We reserve cos=0 as default cbm (all bits within cbm_len are 1).
> */
> -get_cdp_code(feat, 0) = c
On 10/12/2017 04:38 PM, Jan Beulich wrote:
On 11.10.17 at 19:52, wrote:
>> The Intel manual claims that, "If [certain CPUID bits] are set, the
>> processor deprecates FCS and FDS, and the field is saved as h";
>> but experimentally it would be more accurate to say, "the field is
>> occasi
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 useful value.
But what's worse - having read till the end of the patch I don't
see you change any alloca
On 10/13/2017 11:31 AM, Jan Beulich wrote:
On 13.10.17 at 12:23, wrote:
>> On 10/13/2017 10:20 AM, Jan Beulich wrote:
>> On 13.10.17 at 11:10, wrote:
On 10/13/2017 10:06 AM, Jan Beulich wrote:
On 13.10.17 at 11:00, wrote:
>> --- a/tools/fuzz/x86_instruction_emulator/af
Wei Liu writes ("Re: [PATCH] libxl: dm_restrict: DEFINE_USERLOOKUP_HELPER
returned a pointer to an auto"):
> On Fri, Oct 13, 2017 at 11:25:59AM +0100, Ian Jackson wrote:
> > When I converted the previous open-coded user lookup functionality
> > into DEFINE_USERLOOKUP_HELPER, I moved the struct pas
>>> On 13.10.17 at 12:23, wrote:
> On 10/13/2017 10:20 AM, Jan Beulich wrote:
> On 13.10.17 at 11:10, wrote:
>>> On 10/13/2017 10:06 AM, Jan Beulich wrote:
>>> On 13.10.17 at 11:00, wrote:
> --- a/tools/fuzz/x86_instruction_emulator/afl-harness.c
> +++ b/tools/fuzz/x86_instructio
>>> On 12.10.17 at 11:10, wrote:
> --- a/xen/arch/x86/hvm/monitor.c
> +++ b/xen/arch/x86/hvm/monitor.c
> @@ -74,16 +74,19 @@ bool hvm_monitor_emul_unimplemented(void)
> monitor_traps(curr, true, &req) == 1;
> }
>
> -void hvm_monitor_msr(unsigned int msr, uint64_t value)
> +void hvm_mon
On Fri, Oct 13, 2017 at 11:25:59AM +0100, Ian Jackson wrote:
> When I converted the previous open-coded user lookup functionality
> into DEFINE_USERLOOKUP_HELPER, I moved the struct passwd buffer into
> the function generated by the macro. This is wrong because that
> buffer is used by get{pw,gr}*
When I converted the previous open-coded user lookup functionality
into DEFINE_USERLOOKUP_HELPER, I moved the struct passwd buffer into
the function generated by the macro. This is wrong because that
buffer is used by get{pw,gr}* for its return value, so the helper
function would contrive to retur
On 10/13/2017 10:20 AM, Jan Beulich wrote:
On 13.10.17 at 11:10, wrote:
>> On 10/13/2017 10:06 AM, Jan Beulich wrote:
>> On 13.10.17 at 11:00, wrote:
--- a/tools/fuzz/x86_instruction_emulator/afl-harness.c
+++ b/tools/fuzz/x86_instruction_emulator/afl-harness.c
@@ -99,13 +
>>> On 13.10.17 at 11:51, wrote:
> On 12/10/17 21:55, Andrew Cooper wrote:
>> On 12/10/2017 21:50, Doug Goldstein wrote:
>>> From: David Esler
>>>
>>> In 9180f5365524 a change was made to the send_chr function to take in
>>> C-strings and print out a character at a time until a NULL was
>>> encou
>>> On 13.10.17 at 11:43, wrote:
> On 10/12/2017 04:24 PM, Jan Beulich wrote:
> On 11.10.17 at 19:52, wrote:
>>> +if ( memcmp(&state[0].regs, &state[1].regs, sizeof(state[0].regs))
>>> )
>>> +{
>>> +printf("registers differ!\n");
>>> +/* Print If Not E
On 10/13/2017 10:54 AM, Jan Beulich wrote:
On 13.10.17 at 11:22, wrote:
>> On 10/12/2017 04:16 PM, Jan Beulich wrote:
>> On 11.10.17 at 19:52, wrote:
@@ -761,12 +757,11 @@ static void disable_hooks(struct x86_emulate_ctxt
*ctxt)
static void sanitize_input(struct x86_emul
>>> On 13.10.17 at 11:22, wrote:
> On 10/12/2017 04:16 PM, Jan Beulich wrote:
> On 11.10.17 at 19:52, wrote:
>>> @@ -761,12 +757,11 @@ static void disable_hooks(struct x86_emulate_ctxt
>>> *ctxt)
>>> static void sanitize_input(struct x86_emulate_ctxt *ctxt)
>>> {
>>> struct fuzz_state
Hi Andrew,
On 12/10/17 21:55, Andrew Cooper wrote:
On 12/10/2017 21:50, Doug Goldstein wrote:
From: David Esler
In 9180f5365524 a change was made to the send_chr function to take in
C-strings and print out a character at a time until a NULL was
encountered. However there is no code to increme
>>> On 11.10.17 at 18:26, wrote:
> @@ -4568,6 +4571,32 @@ static int do_altp2m_op(
> a.u.set_mem_access.view);
> break;
>
> +case HVMOP_altp2m_set_mem_access_multi:
> +if ( a.u.set_mem_access_multi.pad ||
> + a.u.set_mem_acces
Hi Andrew,
On 12/10/17 14:54, Andrew Cooper wrote:
The important change here is in patch 3, which is intended to remove the
correct-but-dangerous-looking construction of linear pagetables slots for
shadowed guests.
Release-acked-by: Julien Grall
Cheers,
Andrew Cooper (3):
Revert "x86/m
On 10/12/2017 04:24 PM, Jan Beulich wrote:
On 11.10.17 at 19:52, wrote:
>> @@ -884,20 +891,146 @@ int LLVMFuzzerInitialize(int *argc, char ***argv)
>> return 0;
>> }
>>
>> -int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t size)
>> +static void setup_fuzz_state(struct fuzz_stat
Hi Jan,
On 12/10/17 10:38, Jan Beulich wrote:
The first two patches are bug fixes and hence candidates for 4.10.
The 3rd is mostly cleanup, and hence intended only for after 4.10.
1: request page table page-in for the correct domain
2: fix do_update_va_mapping_otherdomain() wrt translated domai
>>> On 13.10.17 at 10:14, wrote:
> On Fri, Oct 13, 2017 at 02:25:38AM -0600, Jan Beulich wrote:
> On 09.10.17 at 23:32, wrote:
>>> +{
>>> +if ( unlikely(vec < 16) )
>>> +return false;
>>> +
>>> +if ( hvm_funcs.sync_pir_to_irr )
>>> +hvm_funcs.sync_pir_to_irr(vlapic_vcp
On 10/12/2017 04:16 PM, Jan Beulich wrote:
On 11.10.17 at 19:52, wrote:
>> --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>> +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>> @@ -22,34 +22,31 @@
>>
>> #define SEG_NUM x86_seg_none
>>
>> -/* Layout of data expected as fuzzing
>>> On 13.10.17 at 11:10, wrote:
> On 10/13/2017 10:06 AM, Jan Beulich wrote:
> On 13.10.17 at 11:00, wrote:
>>> --- a/tools/fuzz/x86_instruction_emulator/afl-harness.c
>>> +++ b/tools/fuzz/x86_instruction_emulator/afl-harness.c
>>> @@ -99,13 +99,17 @@ int main(int argc, char **argv)
>>>
On 13 October 2017 at 00:34, Andrew Cooper wrote:
> On 12/10/17 19:54, Bhupinder Thakur wrote:
>> On 5 October 2017 at 15:07, Wei Liu wrote:
>>> On Wed, Oct 04, 2017 at 09:58:32PM -0400, Konrad Rzeszutek Wilk wrote:
I get this when compiling under ARM32 (Ubuntu 15.04,
gcc (Ubuntu/Linaro
On Fri, Oct 13, 2017 at 02:25:38AM -0600, Jan Beulich wrote:
On 09.10.17 at 23:32, wrote:
>
>First of all - please use a better subject. If someone finds another
>bug in this function in, say, half a year's time, how will we tell apart
>the two patches from looking at just the list of titles
On 10/13/2017 10:06 AM, Jan Beulich wrote:
On 13.10.17 at 11:00, wrote:
>> Changeset introduced "batch mode" to afl-harness, which allowed
>
> With (part of) the commit hash and the title inserted here and ...
This should be `2b1cde7783` BTW.
-George
On 10/13/2017 10:06 AM, Jan Beulich wrote:
On 13.10.17 at 11:00, wrote:
>> Changeset introduced "batch mode" to afl-harness, which allowed
>
> With (part of) the commit hash and the title inserted here and ...
Gah. :-)
>
>> --- a/tools/fuzz/x86_instruction_emulator/afl-harness.c
>> +
>>> On 13.10.17 at 11:00, wrote:
> Changeset introduced "batch mode" to afl-harness, which allowed
With (part of) the commit hash and the title inserted here and ...
> --- a/tools/fuzz/x86_instruction_emulator/afl-harness.c
> +++ b/tools/fuzz/x86_instruction_emulator/afl-harness.c
> @@ -99,
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Andrew Cooper
> Sent: 13 October 2017 10:00
> To: Ross Lagerwall ; Ian Jackson
> ; qemu-de...@nongnu.org
> Cc: Anthony Perard ; Juergen Gross
> ; Stefano Stabellini ; xen-
> de...@lists.xenproject
This patch adds MBA description in related documents.
Signed-off-by: Yi Sun
Acked-by: Wei Liu
Reviewed-by: Roger Pau Monné
---
CC: Ian Jackson
CC: Wei Liu
CC: Roger Pau Monné
CC: Chao Peng
v5:
- remove 'closed-loop' in 'xl-psr.markdown'
(suggested by Roger Pau Monné)
v4:
- mo
This patch implements get HW info flow for MBA including its callback
function and sysctl interface.
Signed-off-by: Yi Sun
Reviewed-by: Roger Pau Monné
Acked-by: Jan Beulich
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: Roger Pau Monné
CC: Chao Peng
v7:
- change 'PSR_INFO_IDX_
This patch implements get value domctl interface for MBA.
Signed-off-by: Yi Sun
Reviewed-by: Roger Pau Monné
Acked-by: Jan Beulich
---
CC: Andrew Cooper
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Chao Peng
v5:
- use newly defined macro to get MBA thrtl.
(suggested by Ro
This patch implements set value flow for MBA including its callback
function and domctl interface.
Signed-off-by: Yi Sun
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: Roger Pau Monné
CC: Chao Peng
v7:
- change name of 'check_val' to 'sanitize'.
(suggested by Jan Beulich)
This patch creates MBA feature document in doc/features/. It describes
key points to implement MBA which is described in details in Intel SDM
"Introduction to Memory Bandwidth Allocation".
Signed-off-by: Yi Sun
Reviewed-by: Roger Pau Monné
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC:
This patch renames 'xc_psr_cat_type' to 'xc_psr_type' so that
the structure name is common for all allocation features.
Signed-off-by: Yi Sun
Acked-by: Wei Liu
Reviewed-by: Chao Peng
Reviewed-by: Roger Pau Monné
---
CC: Ian Jackson
CC: Wei Liu
CC: Roger Pau Monné
CC: Chao Peng
v5:
- r
1 - 100 of 127 matches
Mail list logo
