>>> On 11.10.17 at 17:41, wrote:
> Return 0 to indicate success rather than whatever rc was previously set
> to (-EINVAL).
>
> Signed-off-by: Ross Lagerwall
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-deve
>>> On 11.10.17 at 15:59, wrote:
> Now that "x86/hvm: implement hvmemul_write() using real mappings" is in,
> we can start working again on implementing hvmemul_cmpxchg() with a real
> CMPXCHG, and finally fix the SMP emulation race upstream.
That's my plan, but this will end up being complete
+ret = -1;
> +break;
> +}
> }
> -return 0;
> +if ( (parms->virt_base != UNSET_ADDR) &&
Please add a blank line ahead of this addition.
With those taken care of
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 08.10.17 at 09:23, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -138,6 +138,12 @@ static const struct feat_props {
>
> /* write_msr is used to write out feature MSR register. */
> void (*write_msr)(unsigned int cos, uint32_t val, enum psr_type type);
> +
> +
>>> On 08.10.17 at 09:23, wrote:
> 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
with one further adjustment:
> --- a/xen/includ
>>> On 20.09.17 at 21:50, wrote:
> It's a leftover from PVHv1 days.
>
> Signed-off-by: Boris Ostrovsky
I've applied this despite the still missing VMX maintainer ack,
for it being simple enough. But in general it should be you to
chase missing acks.
Jan
__
>>> On 11.10.17 at 14:03, wrote:
> When filling __xen_guest section of a guest, user may define
> HYPERCALL_PAGE earlier than VIRT_BASE in the section leading to an
> incorrect hypercall page address since an undefined virt_base could be
> used to compute hypercall page address.
> If there is no V
UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6)
> +#endif /* defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L */
Same for the comment here. I'd suggest either dropping it altogether
or shortening it (e.g. /* __STDC_VERSION__ / __GNUC__ */)
All of these adjustment
>>> On 11.10.17 at 14:12, wrote:
> On 11.10.17 11:07, Jan Beulich wrote:
>>>>> On 10.10.17 at 19:03, wrote:
>>> On 10.10.17 19:12, Jan Beulich wrote:
>>>>>>> On 10.10.17 at 17:52, wrote:
>>>>> +uint8_t a[16];
>
>>> On 11.10.17 at 09:20, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -,25 +,43 @@ static unsigned int get_socket_cpu(unsigned int
> socket)
> struct cos_write_info
> {
> unsigned int cos;
> -struct feat_node *feature;
> const uint32_t *val;
> -co
id) = 0; (id) < MAX_NR_IOREQ_SERVERS; (id)++ ) \
> +if ( !(s = GET_IOREQ_SERVER((d), (id))) ) \
The two pairs of innermost parentheses are pointless here.
With the first one at least explained and the second one taken
care of (easily doable at commit time)
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 11.10.17 at 13:23, wrote:
> On 11/10/17 08:44, Jan Beulich wrote:
>>>>> On 10.10.17 at 14:43, wrote:
>>> On 10/10/17 11:43, Jan Beulich wrote:
>>>> There's another issue here, but I'll first have to think about possible
>>&g
>>> On 11.10.17 at 05:03, wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1105,7 +1105,13 @@ static void dma_msi_set_affinity(struct irq_desc
> *desc, const cpumask_t *mask)
>
> spin_lock_irqsave(&iommu->register_lock, flags);
> dma
>>> On 10.10.17 at 17:04, wrote:
> On Wed, Oct 04, 2017 at 08:34:43AM +, Jan Beulich wrote:
>> >>> On 19.09.17 at 17:29, wrote:
>> > --- a/xen/include/xen/vpci.h
>> > +++ b/xen/include/xen/vpci.h
>> > @@ -100,6 +100,40 @@
>>> On 10.10.17 at 13:35, wrote:
> On Wed, Oct 04, 2017 at 08:34:13AM +, Jan Beulich wrote:
>> >>> On 19.09.17 at 17:29, wrote:
>> > --- a/xen/include/xen/vpci.h
>> > +++ b/xen/include/xen/vpci.h
>> > @@ -72,6 +72,30 @@ struct vpci {
&g
>>> On 10.10.17 at 23:00, wrote:
> On Tue, 2017-10-10 at 06:28 -0600, Jan Beulich wrote:
>> > > > +typedef struct xen_hvm_altp2m_set_mem_access_multi
>> > +xen_hvm_altp2m_set_mem_access_multi_t;
>> > +DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_se
>>> On 11.10.17 at 11:54, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 11 October 2017 10:43
>> Hmm, that would be an option, but I'd prefer if we could get away
>> without. And no, I wasn't suggesting to introduce yet another
>>
sfer: can't find domain %d\n",
> -gop.domid);
> + gdprintk(XENLOG_INFO, "can't find domain %d\n", gop.domid);
d%d here too?
If you decide to take care of all of the above, then
Acked-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 11.10.17 at 10:54, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 11 October 2017 09:47
>> >>> On 10.10.17 at 18:01, wrote:
>> >> > @@ -993,6 +1018,11 @@ static int acquire_re
>>> On 11.10.17 at 11:29, wrote:
> Hi Jan,
>
> On 11/10/17 09:54, Jan Beulich wrote:
>>>>> On 11.10.17 at 01:24, wrote:
>>> On Tue, 10 Oct 2017, Volodymyr Babchuk wrote:
>>>> --- a/xen/include/public/xen.h
>>>> +++ b/xen/includ
g infinite number of
> instruction retries for the old (non-compact) format does indeed speed
> up and increase code coverage. However, it has also shown that on the
> new, more compact format, having no instruction limit causes the highest
> throughput in code coverage.
>
>
>>> On 10.10.17 at 18:20, wrote:
> --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
> +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
> @@ -40,6 +40,8 @@ struct fuzz_state
> uint64_t msr[MSR_INDEX_MAX];
> struct segment_register segments[SEG_NUM];
> struct cpu_user_regs r
>>> On 10.10.17 at 20:44, wrote:
> On 10/10/17 17:20, George Dunlap wrote:
>> +if ( state[0].elem != state[1].elem ) \
>> +printf(#elem " differ: %lx != %lx\n", \
>> + (unsigned long)state[0].elem, \
>> + (unsigned long)state[
ormance comparison of the old and new formats.
>
> Signed-off-by: George Dunlap
Without meaning to override Andrew's objections, in case
he can grudgingly accept this going in
Acked-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
it in
>> fuzz-emul.c).
>>
>> Signed-off-by: George Dunlap
>
> Reviewed-by: Ian Jackson
Acked-by: Jan Beulich
(also if you add ...
>> RFC: Worth trying to BUILD_BUG_ON(INPUT_SIZE < DATA_SIZE_FULL)?
>
> I don't mind.
... this)
___
tion in the first
> place), it seems to make more sense to rename the file anyway.
>
> Signed-off-by: George Dunlap
> Acked-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 10.10.17 at 19:22, wrote:
> George Dunlap writes ("[PATCH v3 01/12] fuzz/x86_emulate: Clear errors after
> each iteration"):
>> Once feof() returns true for a stream, it will continue to return true
>> for that stream until clearerr() is called (or the stream is closed
>> and re-opened).
>
>>> On 10.10.17 at 18:47, wrote:
> On 10/10/2017 05:20 PM, George Dunlap wrote:
>> Once feof() returns true for a stream, it will continue to return true
>> for that stream until clearerr() is called (or the stream is closed
>> and re-opened).
>>
>> In llvm-clang-fast-mode, the same file descript
>>> On 11.10.17 at 01:24, wrote:
> On Tue, 10 Oct 2017, Volodymyr Babchuk wrote:
>> --- a/xen/include/public/xen.h
>> +++ b/xen/include/public/xen.h
>> @@ -930,6 +930,39 @@ __DEFINE_XEN_GUEST_HANDLE(uint16, uint16_t);
>> __DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t);
>> __DEFINE_XEN_GUEST_HANDLE(u
>>> On 11.10.17 at 10:38, wrote:
> Separate permissions could be an option, but maybe it would be better just
> to introduce a new resource mapping permission. I'll probably go with the
> latter.
Oh, I'm certainly fine with that, it just means more changes.
Jan
__
>>> On 10.10.17 at 18:01, wrote:
>> > @@ -3795,6 +3807,18 @@ int gnttab_map_frame(struct domain *d,
>> unsigned long idx, gfn_t gfn,
>> > return rc;
>> > }
>> >
>> > +int gnttab_get_frame(struct domain *d, unsigned long idx, mfn_t *mfn)
>>
>> const struct domain * (I realize now that the sa
>>> On 10.10.17 at 16:45, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 09 October 2017 16:21
>> >>> On 06.10.17 at 14:25, wrote:
>> > @@ -784,6 +885,45 @@ int hvm_get_ioreq_server_info(struct domain *d,
>> ioservi
>>> On 10.10.17 at 16:37, wrote:
>> From: Paul Durrant
>> Sent: 10 October 2017 15:10
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: 09 October 2017 15:23
>> > To: Paul Durrant
>> > >>> On 06.10.17 at 14:25, wrote:
>>> On 10.10.17 at 15:26, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 09 October 2017 14:06
>> >>> On 06.10.17 at 14:25, wrote:
>> > --- a/xen/common/memory.c
>> > +++ b/xen/common/memory.c
>> > @@ -965,6 +
>>> On 10.10.17 at 20:08, wrote:
> On 10/10/2017 05:24 PM, Jan Beulich wrote:
>>>>> On 10.10.17 at 16:13, wrote:
>>> On Ma, 2017-10-10 at 06:28 -0600, Jan Beulich wrote:> >
>>>&g
>>> On 10.10.17 at 19:03, wrote:
> On 10.10.17 19:12, Jan Beulich wrote:
>>>>> On 10.10.17 at 17:52, wrote:
>>> +uint8_t a[16];
>>> +} xen_uuid_t;
>>> +
>>> +/*
>>> + * XEN_DEFINE_UUID(0x00112233, 0x4455, 0x
>>> On 10.10.17 at 14:43, wrote:
> On 10/10/17 11:43, Jan Beulich wrote:
>> There's another issue here, but I'll first have to think about possible
>> (preferably non-intrusive) solutions: An access crossing a page
>> boundary and having
>> - a
>>> On 10.10.17 at 17:52, wrote:
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -930,6 +930,39 @@ __DEFINE_XEN_GUEST_HANDLE(uint16, uint16_t);
> __DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t);
> __DEFINE_XEN_GUEST_HANDLE(uint64, uint64_t);
>
> +typedef struct
> +{
Please
>>> On 08.10.17 at 09:23, wrote:
> This patch implements main data structures of MBA.
>
> Like CAT features, MBA HW info has cos_max which means the max thrtl
> register number, and thrtl_max which means the max throttle value
> (delay value). It also has a flag to represent if the throttle
> val
fine a local variable 'feat_mask' in 'psr_cpu_init' to reduce calling
> of
>'cpuid_count_leaf()'.
>
> Signed-off-by: Yi Sun
> Reviewed-by: Roger Pau Monné
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
very least I'd like to ask for the #define to be moved
inside the switch() statement, and the #undef ahead of
default:.
With these taken care of
Acked-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 10.10.17 at 11:19, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -,25 +,47 @@ static unsigned int get_socket_cpu(unsigned int
> socket)
> struct cos_write_info
> {
> unsigned int cos;
> -struct feat_node *feature;
> +struct feat_node **features;
>>> On 10.10.17 at 16:13, wrote:
> On Ma, 2017-10-10 at 06:28 -0600, Jan Beulich wrote:> >
>> > >
>> > > >
>> > > > a.u.set_mem_access_multi.pfn_list,
>> > +
>>> On 09.10.17 at 19:30, wrote:
> @@ -4568,6 +4571,30 @@ 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
>>> On 09.10.17 at 12:56, wrote:
> +static void *hvmemul_map_linear_addr(
> +unsigned long linear, unsigned int bytes, uint32_t pfec,
> +struct hvm_emulate_ctxt *hvmemul_ctxt)
> +{
> +struct vcpu *curr = current;
> +void *err, *mapping;
> +unsigned int nr_frames = ((linear + by
writes.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
---
There's another issue here, but I'll first have to think about possible
(preferably non-intrusive) solutions: An access crossing a page
boundary and having
- a set mask bit corresponding to an element fully living in the fir
>>> On 06.10.17 at 14:25, wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3756,14 +3756,13 @@ int mem_sharing_gref_to_gfn(struct grant_table *gt,
> grant_ref_t ref,
> }
> #endif
>
> -int gnttab_map_frame(struct domain *d, unsigned long idx, gfn_t gfn,
> -
>>> On 10.10.17 at 11:14, wrote:
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -238,10 +238,17 @@ static __always_inline u64
> steal_account_process_time(u64 maxtime)
> {
> #ifdef CONFIG_PARAVIRT
> if (static_key_false(¶virt_steal_enabled)) {
> - u64 steal
>>> On 09.10.17 at 17:36, wrote:
> On 09/14/2017 04:12 PM, Jan Beulich wrote:
>> @@ -7119,6 +7142,18 @@ x86_emulate(
>> fic.insn_bytes = PFX_BYTES + 3;
>> break;
>>
>> +case X86EMUL_OPC_VEX_66(0x0f38, 0x19): /* vbroadcastsd m64,ymm
_t *pl1e, l1_pgentry_t nl1e,
> -unsigned long gl1mfn, int preserve_ad,
> +unsigned long gl1mfn, int cmd,
unsigned int
With that
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 06.10.17 at 14:25, wrote:
> @@ -288,6 +301,61 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s,
> bool buf)
> return rc;
> }
>
> +static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
> +{
> +struct domain *currd = current->domain;
> +struct hvm_ior
>>> On 09.10.17 at 16:38, wrote:
> On 09/10/17 15:36, Jan Beulich wrote:
>>>>> On 09.10.17 at 16:11, wrote:
>>> --- a/xen/common/ubsan/ubsan.c
>>> +++ b/xen/common/ubsan/ubsan.c
>>> @@ -10,13 +10,18 @@
>>> *
>>&g
>>> On 09.10.17 at 16:11, wrote:
> --- a/xen/common/ubsan/ubsan.c
> +++ b/xen/common/ubsan/ubsan.c
> @@ -10,13 +10,18 @@
> *
> */
>
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> +#include
> +#include
> +
> +#define __noreturnnoreturn
> +#d
>>> On 06.10.17 at 14:25, wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -965,6 +965,67 @@ static long xatp_permission_check(struct domain *d,
> unsigned int space)
> return xsm_add_to_physmap(XSM_TARGET, current->domain, d);
> }
>
> +#ifdef CONFIG_X86
> +static int a
>>> On 09.10.17 at 15:48, wrote:
> On 09/10/17 14:40, Jan Beulich wrote:
>>>>> On 09.10.17 at 14:20, wrote:
>>> On 09/10/17 12:42, Jan Beulich wrote:
>>>>>>> On 05.10.17 at 19:42, wrote:
>>>>> --- a/xen/arch/arm/dom
>>> On 09.10.17 at 14:20, wrote:
> Hi Jan,
>
> On 09/10/17 12:42, Jan Beulich wrote:
>>>>> On 05.10.17 at 19:42, wrote:
>>> --- a/xen/arch/arm/domain_build.c
>>> +++ b/xen/arch/arm/domain_build.c
>>> @@ -50,8 +50,6 @@ struct map_rang
>>> On 09.10.17 at 14:54, wrote:
> On 25/09/17 15:26, George Dunlap wrote:
>> From: Jan Beulich
>>
>> fuzz_insn_fetch() is the only data access helper where it is possible
>> to see offsets larger than 4Gb in 16- or 32-bit modes, as we leave the
>> inc
>>> On 06.10.17 at 14:25, wrote:
> @@ -395,6 +397,39 @@ int compat_memory_op(unsigned int cmd,
> XEN_GUEST_HANDLE_PARAM(void) compat)
> }
> #endif
>
> +case XENMEM_acquire_resource:
> +{
> +xen_ulong_t *gmfn_list = (xen_ulong_t *)(nat.mar + 1);
> +
> +
q_handling != HVM_IOREQSRV_BUFIOREQ_OFF)
Didn't I point out already that s wants to be parenthesized here?
Or was that on another macro? With this taken care of
Reviewed-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 06.10.17 at 14:25, wrote:
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -33,6 +33,44 @@
>
> #include
>
> +static void set_ioreq_server(struct domain *d, unsigned int id,
> + struct hvm_ioreq_server *s)
> +{
> +ASSERT(id < MAX_NR
>>> On 09.10.17 at 13:08, wrote:
> On 09/04/2017 09:47 AM, Jan Beulich wrote:
>>>>> On 01.09.17 at 18:28, wrote:
>>> On 01/09/17 17:18, Jan Beulich wrote:
>>>> There is no need to hold the global domctl lock while across
>>>&
>>> On 09.10.17 at 13:19, wrote:
> On Lu, 2017-10-09 at 04:36 -0600, Jan Beulich wrote:
>> > > > On 09.10.17 at 12:10, wrote:
>> > On Vi, 2017-10-06 at 09:34 -0600, Jan Beulich wrote:
>> > > > > > On 05.10.17 at 17:42, wrote:
>>
>>> On 05.10.17 at 19:42, wrote:
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -50,8 +50,6 @@ struct map_range_data
> /* Override macros from asm/page.h to make them work with mfn_t */
> #undef virt_to_mfn
> #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
> -#unde
>>> On 09.10.17 at 12:10, wrote:
> On Vi, 2017-10-06 at 09:34 -0600, Jan Beulich wrote:
>> > > > On 05.10.17 at 17:42, wrote:
>> > +switch ( a.cmd )
>> > +{
>> > +case HVMOP_altp2m_set_mem_access_multi:
>> >
l values (i.e., some of the values used by Linux as
> the tick frequency) are 10, 4 or 1 ms. Default valus (used
> when this parameter is not specified) is 10ms. Maximum is
> 100ms.
>
> Signed-off-by: Dario Faggioli
Reviewed-by: Jan Beulich
__
>>> On 09.10.17 at 11:49, wrote:
> On 09/10/17 08:48, Jan Beulich wrote:
>> Halfway recent Linux kernels probe MISC_FEATURES_ENABLES on all CPUs,
>> leading to ugly recovered #GP fault messages with debug builds on older
>> systems. We can do better, so introdu
double blank lines. Instead, insert the
new function between the two existing ones.
With at least the latter addressed
Reviewed-by: Jan Beulich
Of course both should be easy to take care of while committing,
should no other reason arise for sending v4.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 06.10.17 at 19:41, wrote:
> @@ -40,7 +38,8 @@ struct xencons_interface {
> XENCONS_RING_IDX out_cons, out_prod;
> };
>
> -#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> +#if defined(XEN_WANT_FLEX_CONSOLE_RING)
With this becoming #i
>>> On 09.10.17 at 08:00, wrote:
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -122,8 +122,6 @@ int physdev_map_pirq(domid_t domid, int type, int *index,
> int *pirq_p,
> break;
>
> case MAP_PIRQ_TYPE_MSI:
> -if ( !msi->table_base )
> -msi-
>>> On 08.10.17 at 07:29, wrote:
> Whatever the fix would be applied to guest kernel side, I think the root cause
> is because xen hypervisor returns a RUNSTATE_runnable time less than the
> previous one before live migration.
>
> As I am not clear enough with xen scheduling, I do not understand
>>> On 06.10.17 at 18:53, wrote:
> On Sat, Sep 30, 2017 at 01:39:12AM +, Yi Sun wrote:
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -37,6 +37,16 @@
>> #include
>> #include
>>
>> +#define domctl_psr_get_val(d, domctl, type, copyback) ({ \
>> +int r__;
Therefore all write attempts should produce #GP, just like on real
hardware.
Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
v2: Group case label with other r/o MSRs.
---
Assumed to be applied on top of the (trivial) backport of 46c3acb308
("x86/vvmx: Fix WRMSR interception o
nature of PLATFORM_INFO is now also being enforced.
The rdmsr_safe() uses for MISC_ENABLE are left in place as benign - it
exists for all 64-bit capable Intel CPUs (see e.g. early_init_intel()).
Signed-off-by: Jan Beulich
---
v2: Force PLATFORM_INFO writes to fail.
--- a/xen/arch/x86/cpu/intel.c
>>> On 06.10.17 at 18:07, wrote:
> On 10/06/2017 06:34 PM, Jan Beulich wrote:
>>>>> On 05.10.17 at 17:42, wrote:
>>> @@ -4451,6 +4453,7 @@ static int do_altp2m_op(
>>> case HVMOP_altp2m_destroy_p2m:
>>> case HVMOP_altp2m
>>> On 06.10.17 at 19:06, wrote:
> On 10/06/2017 04:54 PM, Jan Beulich wrote:
>>>>> On 06.10.17 at 17:21, wrote:
>>> On Mon, Sep 25, 2017 at 3:26 PM, George Dunlap
>>> wrote:
> One more thing:
>
>> @@ -1249,10 +1249,10 @@ static voi
>>> On 06.10.17 at 17:21, wrote:
> On Mon, Sep 25, 2017 at 3:26 PM, George Dunlap
> wrote:
>> From: Jan Beulich
>>
>> fuzz_insn_fetch() is the only data access helper where it is possible
>> to see offsets larger than 4Gb in 16- or 32-bit modes, as we lea
>>> On 05.10.17 at 17:42, wrote:
> @@ -4451,6 +4453,7 @@ static int do_altp2m_op(
> case HVMOP_altp2m_destroy_p2m:
> case HVMOP_altp2m_switch_p2m:
> case HVMOP_altp2m_set_mem_access:
> +case HVMOP_altp2m_set_mem_access_multi:
Was it agreed that this, just like others (many wron
>>> On 02.10.17 at 14:23, wrote:
> +static void *hvmemul_map_linear_addr(
> +unsigned long linear, unsigned int bytes, uint32_t pfec,
> +struct hvm_emulate_ctxt *hvmemul_ctxt)
> +{
> +struct vcpu *curr = current;
> +void *err, *mapping;
> +
> +/* First and final gfns which need
dler
> http://elixir.free-electrons.com/linux/latest/source/drivers/tty/serial/8250/
> 8250_dw.c#L233
>
> Tested on Orange Pi PC2 (H5). This issue is seen on H3
> as well and the same fix works.
>
> Signed-off-by: Awais Masood
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 06.10.17 at 16:21, wrote:
> On 09/14/2017 04:16 PM, Jan Beulich wrote:
>> Make i switch-wide (at once making it unsigned, as it should have been)
>> and introduce n (for immediate use in enter and aam/aad handling).
>> Eliminate on-stack arrays in pusha/popa h
ff-by: Volodymyr Babchuk
>
> Acked-by: Julien Grall
>
> Note that an acked-by/reviewed-by "THE REST" is still needed on this patch.
Here you go:
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
All,
with the goal of releasing around the end of the month, please point
out backport candidates you find missing from the respective staging
branches, but which you consider relevant. Note that commits
1c2ea5ee05 x86/hvm/dmop: fix EFAULT condition
4e383df865 x86/PV: fix/generalize guest nul sel
>>> On 06.10.17 at 13:48, wrote:
> @@ -40,7 +38,9 @@ struct xencons_interface {
> XENCONS_RING_IDX out_cons, out_prod;
> };
>
> -#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> +#if defined(__GNUC__) && !defined(__STRICT_ANSI__) && \
> +defined(XEN_WANT_FLEX_CONSOLE_RING)
> +#incl
>>> On 06.10.17 at 12:40, wrote:
> On 10/04/2017 09:28 AM, Jan Beulich wrote:
>>>>> On 25.09.17 at 16:26, wrote:
>>> AFL considers a testcase to be a useful addition not only if there are
>>> tuples exercised by that testcase which were not exercis
>>> On 25.09.17 at 16:26, wrote:
> @@ -597,6 +599,47 @@ static const struct x86_emulate_ops all_fuzzer_ops = {
> };
> #undef SET
>
> +static void _set_fpu_state(char *fxsave, bool store)
> +{
> +if ( cpu_has_fxsr )
> +{
> +static union __attribute__((__aligned__(16))) {
> +
>>> On 06.10.17 at 12:50, wrote:
> On 10/06/2017 10:57 AM, Jan Beulich wrote:
>>>>> On 05.10.17 at 19:08, wrote:
>>> On 10/04/2017 09:28 AM, Jan Beulich wrote:
>>>>>>> On 25.09.17 at 16:26, wrote:
>>>>>
>>> On 05.10.17 at 19:08, wrote:
> On 10/04/2017 09:28 AM, Jan Beulich wrote:
>>>>> On 25.09.17 at 16:26, wrote:
>>> @@ -597,6 +599,47 @@ static const struct x86_emulate_ops all_fuzzer_ops = {
>>> };
>>> #undef SET
>>
>>> George Dunlap 10/05/17 7:08 PM >>>
>On 10/04/2017 09:28 AM, Jan Beulich wrote:
>>>>> On 25.09.17 at 16:26, wrote:
>>> @@ -597,6 +599,47 @@ static const struct x86_emulate_ops all_fuzzer_ops = {
>>> };
>>> #undef SET
>>> George Dunlap 10/05/17 6:13 PM >>>
>On 10/04/2017 09:27 AM, Jan Beulich wrote:
>>>>> On 25.09.17 at 16:26, wrote:
>>> +if ( memcmp(&state[0], &state[1], sizeof(struct fuzz_state)) )
>>> +{
>>> +int i;
&g
>>> On 05.10.17 at 16:00, wrote:
> I'm currently looking at a problem with a pass-through SR-IOV device where
> the guest driver triggers a VF reset via a back-door interface to the PF. The
> reset completes successfully but, in this scenario, it is up to the PF driver
> running in dom0 to rest
>>> On 05.10.17 at 17:04, wrote:
> On 10/04/2017 09:26 AM, Jan Beulich wrote:
>>>>> On 25.09.17 at 16:26, wrote:
>>> --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>>> +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>>> @@
>>> On 05.10.17 at 14:02, wrote:
> On Thu, Oct 05, 2017 at 11:55:39AM +, Jan Beulich wrote:
>> >>> On 05.10.17 at 13:09, wrote:
>> > On Thu, Oct 05, 2017 at 10:01:46AM +, Jan Beulich wrote:
>> >> >>> On 05.10.17 at 11:20, wro
>>> On 05.10.17 at 13:09, wrote:
> On Thu, Oct 05, 2017 at 10:01:46AM +, Jan Beulich wrote:
>> >>> On 05.10.17 at 11:20, wrote:
>> > On Wed, Oct 04, 2017 at 08:33:33AM +, Jan Beulich wrote:
>> >> >>> On 19.09.17 at 17:29, wrot
>>> On 04.10.17 at 20:26, wrote:
> Hello,
>
> with linux-4.9.52 running on Debian-Wheezy with Xen-4.1 I observed
> several stuck processes: Here is one (truncated) dump of the Linux
> kernel messages:
>
>> [] ? __schedule+0x23d/0x6d0
>> [] ? bit_wait_timeout+0x90/0x90
>> [] ? schedule+0x32/0x
>>> On 05.10.17 at 11:20, wrote:
> On Wed, Oct 04, 2017 at 08:33:33AM +, Jan Beulich wrote:
>> >>> On 19.09.17 at 17:29, wrote:
>> > +static int vpci_check_bar_overlap(const struct pci_dev *pdev,
>> > +
>>> On 05.10.17 at 11:28, wrote:
> On Thu, Oct 05, 2017 at 03:22:33AM -0600, Jan Beulich wrote:
>> >>> On 04.10.17 at 15:51, wrote:
>> > Starting from Xen commit af8d93564, it is required to include string.h
>> > before console.h.
>>
>> B
>>> On 05.10.17 at 10:39, wrote:
> On Thu, Oct 05, 2017 at 04:48:12AM +, Yi Sun wrote:
>> On 17-10-03 23:59:46, Jan Beulich wrote:
>> > >>> Yi Sun 09/29/17 4:58 AM >>>
>> > >On 17-09-28 05:36:11, Jan Beulich wrote:
>> >
>>> On 05.10.17 at 01:27, wrote:
> As for TMEM itself (Julien: This my no means blocks the patch. It is
> more an observation for Konrad to see about fixing), I see that TMEM is
> broken on x86 machines with more than 5TB of RAM, because it is not
> legal to call page_to_virt() on a struct page_i
>>> On 05.10.17 at 10:18, wrote:
> --- a/xen/arch/x86/hvm/vmx/entry.S
> +++ b/xen/arch/x86/hvm/vmx/entry.S
> @@ -80,7 +80,7 @@ UNLIKELY_END(realmode)
> mov %rsp,%rdi
> call vmx_vmenter_helper
> cmp $0,%eax
> -jne .Lvmx_vmentry_restart
> +je .Lvmx_vmentr
>>> On 04.10.17 at 15:51, wrote:
> Starting from Xen commit af8d93564, it is required to include string.h
> before console.h.
But that's broken then - there shouldn't be such an effect for
anyone updating their public headers. IOW I think this needs
to be dealt with by further adjusting console.h
301 - 400 of 13762 matches
Mail list logo
