>>> On 22.11.17 at 18:13, wrote:
> On 11/21/2017 08:52 AM, Jan Beulich wrote:
>>>>> On 13.11.17 at 16:41, wrote:
>>> With the exception of driver domains, which depend on PCI passthrough,
>>> and will be introduced later.
>>>
>>> Si
>>> On 22.11.17 at 19:01, wrote:
>
>> On Nov 21, 2017, at 9:26 AM, Jan Beulich wrote:
>>
>>>>> On 13.11.17 at 16:41, wrote:
>>> +### Virtual CPUs
>>> +
>>> +Limit, x86 PV: 8192
>>> +Limit-security, x
>>> On 22.11.17 at 18:15, wrote:
> On 11/21/2017 07:55 PM, Andrew Cooper wrote:
>> On 13/11/17 15:41, George Dunlap wrote:
>>> Signed-off-by: George Dunlap
>>> ---
>>> CC: Ian Jackson
>>> CC: Wei Liu
>>> CC: Andrew Cooper
>&
>>> On 22.11.17 at 20:20, wrote:
> Core memory management and scheduling.
>
> Signed-off-by: George Dunlap
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 22.11.17 at 20:20, wrote:
> Including host architecture support and guest types.
>
> Signed-off-by: George Dunlap
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.or
>>> On 22.11.17 at 20:20, wrote:
> Superpage support and PVHVM.
>
> Signed-off-by: George Dunlap
Acked-by: Jan Beulich
with one remark:
> +## Scalability
> +
> +### Super page support
> +
> +Status, x86 HVM/PVH, HAP: Supported
> +Status,
>>> On 22.11.17 at 20:20, wrote:
> Mostly PV protocols.
>
> Signed-off-by: George Dunlap
Acked-by: Jan Beulich
with a couple of remarks.
> @@ -223,6 +227,152 @@ which add paravirtualized functionality to HVM guests
> for improved performance and scalability.
> T
>>> On 22.11.17 at 20:20, wrote:
> x86-specific virtual hardware provided by the hypervisor, toolstack,
> or QEMU.
>
> Signed-off-by: George Dunlap
Non-QEMU parts
Acked-by: Jan Beulich
with one typo preferably corrected:
> +### x86/Nested HVM
> +
> +
tems would better require "select"s (unless, like for
ns16550, they're there sort of for documentation / consistency
purpose only).
With this XXX dropped (and with or without adding (x86) to
EHCI)
Acked-by: Jan Beulich
Jan
___
Xen-dev
>>> On 22.11.17 at 20:20, wrote:
> +### Live Patching
> +
> +Status, x86: Supported
> +Status, ARM: Experimental
> +
> +Compile time disabled for ARM
"... by default"?
> +### XSM & FLASK
> +
> +Status: Experimental
> +
> +Compile time disabled.
Same here.
Jan
>>> On 22.11.17 at 20:20, wrote:
> Signed-off-by: George Dunlap
With the XXX suitably addressed
Acked-by: Jan Beulich
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 22.11.17 at 20:20, wrote:
> +XXX Need to check the following:
> +
> + * Guest serial console
> + * Crash kernels
> + * Transcendent Memory
> + * Alternative p2m
> + * vMCE
vMCE has provisions for migration (albeit there has been breakage
here more than once in the past, iirc).
Jan
_
>>> On 22.11.17 at 20:20, wrote:
> +### Virtual RAM
> +
> +Limit-security, x86 PV 64-bit: 2047GiB
> +Limit-security, x86 PV 32-bit: 168GiB (see below)
> +Limit-security, x86 HVM: 1.5TiB
> +Limit, ARM32: 16GiB
> +Limit, ARM64: 1TiB
> +
> +Note that there are no theoretical limit
ned-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1348,28 +1348,41 @@ static int hvmemul_rep_ins(
}
static int hvmemul_rep_outs_set_context(
-enum x86_segment src_seg,
-unsigned long src_offset,
uint16_t dst_port,
unsigned int byt
frames; i++ )
> +{
> +rc = set_foreign_p2m_entry(currd, gfn_list[i],
> + _mfn(mfn_list[i]));
> +if ( rc )
> +{
> +/*
> + * Make sure rc is -EIO for any iteration other t
(shrinking Cc list)
>>> On 23.11.17 at 19:37, wrote:
> On 23/11/17 15:09, Jan Beulich wrote:
>> There were two issues with this function: Its use of
>> hvmemul_do_pio_buffer() was wrong (the function deals only with
>> individual port accesses, not repeated o
>>> On 23.11.17 at 18:08, wrote:
> On 11/23/2017 11:15 AM, Jan Beulich wrote:
>>>>> On 22.11.17 at 20:20, wrote:
>>> +## Debugging, analysis, and crash post-mortem
>>> +
>>> +### Host serial console
>>> +
>>> +Status, NS
>>> On 23.11.17 at 18:21, wrote:
> On 11/23/2017 11:21 AM, Jan Beulich wrote:
>>>>> On 22.11.17 at 20:20, wrote:
>>> +### Virtual RAM
>>> +
>>> +Limit-security, x86 PV 64-bit: 2047GiB
>>> +Limit-security, x86 PV 32-b
>>> On 24.11.17 at 10:36, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 23 November 2017 16:42
>> >>> On 30.10.17 at 18:48, wrote:
>> > +if ( !paging_mode_translate(currd) )
>> > +{
>> > +
st (which may or may not be limited to the domain running the emulator).
>
> NOTE: Use of the new resource type is not compatible with use of
> XEN_DMOP_get_ioreq_server_info unless the XEN_DMOP_no_gfns flag is
> set.
>
> Signed-off-by: Paul Durrant
speaking
the adjustment to handle_pio() isn't needed. Do it nevertheless for
consistency as well as to avoid the lack thereof becoming an issue in
the future; put the main change in generic enough a place to also cover
VMX real mode emulation.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulic
eplace bad ASSERT() in xenmem_add_to_physmap_one()
2: x86: check paging mode earlier in xenmem_add_to_physmap_one()
3: improve XENMEM_add_to_physmap_batch address checking
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject
There are no locks being held, i.e. it is possible to be triggered by
racy hypercall invocations. Subsequent code doesn't really depend on the
checked values, so this is not a security issue.
Signed-off-by: Jan Beulich
---
I'm up for to better suggestions for the EXDEV I've us
There's no point in deferring this until after some initial processing,
and it's actively wrong for the XENMAPSPACE_gmfn_foreign handling to not
have such a check at all.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4081,6 +408
y
issue in this case because of the limited width of struct
xen_add_to_physmap_batch's size field: It being 16-bits wide, only the
r/o M2P area can be accessed. Still we can and should do better.
Signed-off-by: Jan Beulich
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -823,6 +
>>> On 25.11.17 at 19:15, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1286,7 +1286,7 @@ long arch_do_domctl(
> struct xen_domctl_vcpu_msrs *vmsrs = &domctl->u.vcpu_msrs;
> struct xen_domctl_vcpu_msr msr;
> struct vcpu *v;
> -uint32_t
>>> On 24.11.17 at 12:39, wrote:
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -29,6 +29,10 @@
> #ifdef CONFIG_X86
> #include
> #endif
> +#ifdef CONFIG_ACPI
> +#include
> +#endif
> +
>
> /*
No double blank lines please.
Jan
_
>>> On 24.11.17 at 12:39, wrote:
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -1571,6 +1571,30 @@ DT_DEVICE_END
> #endif /* HAS_DEVICE_TREE */
>
> #if defined(CONFIG_ACPI) && defined(CONFIG_ARM)
> +/*
> + * APM X-Gene v1 and v2 UART hardware is an 16550 like devic
>>> On 27.11.17 at 12:27, wrote:
> On Thu, Nov 16, 2017 at 05:22:43PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Thu, Nov 09, 2017 at 11:13:46AM +, Roger Pau Monne wrote:
>> > --- a/xen/include/xen/coverage.h
>> > +++ b/xen/include/xen/coverage.h
>> > @@ -1,9 +1,14 @@
>> > #ifndef _XEN_COV_H
>
>>> On 27.11.17 at 12:37, wrote:
> On 27/11/17 09:53, Jan Beulich wrote:
>>>>> On 25.11.17 at 19:15, wrote:
>>> @@ -1311,10 +1311,49 @@ long arch_do_domctl(
>>> vmsrs->msr_count = nr_msrs;
>>> else
>>&
oolstack context.
>
> Signed-off-by: Andrew Cooper
With the further intentions mentioned in the description (as a
justification for some of the earlier requested changes to not
be done), as indicated in a late response to v1
Reviewed-by: Jan Beulich
Jan
___
>
> Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 09.11.17 at 12:13, wrote:
> Use autodetect only.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 09.11.17 at 12:13, wrote:
> So that other implementations of the sysctl can be added.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenp
>>> On 09.11.17 at 12:13, wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -115,9 +115,13 @@ subdir-all := $(subdir-y) $(subdir-n)
>
> $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS +=
> -DINIT_SECTIONS_ONLY
>
> -ifeq ($(CONFIG_GCOV),y)
> +ifeq ($(CONFIG_COVERAGE),y)
> +ife
>>> On 09.11.17 at 12:13, wrote:
> Introduce the functionality in order to fill the hooks of the
> cov_sysctl_ops struct. Note that the functionality is still not wired
> into the build system.
>
> Signed-off-by: Roger Pau Monné
>>> On 27.11.17 at 15:48, wrote:
> On 11/23/2017 11:17 AM, Jan Beulich wrote:
>>>>> On 22.11.17 at 20:20, wrote:
>>> Signed-off-by: George Dunlap
>>
>> With the XXX suitably addressed
>> Acked-by: Jan Beulich
>
> Would you gi
>>> On 10.11.17 at 11:36, wrote:
> Signed-off-by: Yang Zhong
First and foremost - did you try out your own patch? There not being
any (minimal) test added makes this at least questionable.
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -385,6
>>> On 10.11.17 at 11:36, wrote:
> @@ -7672,7 +7673,12 @@ x86_emulate(
> host_and_vcpu_must_have(pclmulqdq);
> if ( vex.opcx == vex_none )
> goto simd_0f3a_common;
> -generate_exception_if(vex.l, EXC_UD);
> +if ( !vex.l )
> +{
> +g
>>> On 10.11.17 at 11:36, wrote:
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1626,6 +1626,7 @@ static bool vcpu_has(
> #define vcpu_has_clwb()vcpu_has( 7, EBX, 24, ctxt, ops)
> #define vcpu_has_sha() vcpu_has(
>>> On 27.11.17 at 16:41, wrote:
> If it is possible we would like to have the Xen image higher than the
> booloader put it and certainly do not overwrite the Xen code and data
> during copy/relocation. Otherwise the Xen may crash silently at boot.
Is this something that you've actually observed
>>> On 26.10.17 at 19:03, wrote:
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -361,6 +361,40 @@ static void reg_write(struct cpu_user_regs *regs,
> *pval = value;
> }
>
> +static int operand_read(void *buf, struct vmx_inst_op *op,
> +
>>> On 26.10.17 at 19:03, wrote:
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -1801,7 +1801,7 @@ int nvmx_handle_vmptrst(struct cpu_user_regs *regs)
> unsigned long gpa = 0;
> int rc;
>
> -rc = decode_vmx_inst(regs, &decode, &gpa, 0);
> +rc = de
>>> On 27.11.17 at 17:58, wrote:
> On 27/11/17 15:41, Daniel Kiper wrote:
>> If it is possible we would like to have the Xen image higher than the
>> booloader put it and certainly do not overwrite the Xen code and data
>> during copy/relocation. Otherwise the Xen may crash silently at boot.
>>
>>
>>> On 27.11.17 at 20:54, wrote:
> If the user decides to put the kexec crashkernel in the same
> area (so at the end of the E820_RAM) the relocation routines
> go haywire. For example with " crashkernel=512M@3327M"
>
> we would be usurping the end of the E820_RAM.
I'm tempte
>>> On 27.11.17 at 20:43, wrote:
> what version of gcc do Xen developers use for Xen? Is gcc 5.4 or 6.4 safe
> to use?
I think it's the other way around - if you find issues with any gcc
version new enough for the build process to not bail out, and which
aren't described anywhere already, point
>>> On 26.10.17 at 19:03, wrote:
> +static int operand_read(void *buf, struct vmx_inst_op *op,
> +struct cpu_user_regs *regs, unsigned int bytes)
const (twice)
> +{
> +if ( op->type == VMX_INST_MEMREG_TYPE_REG )
> +{
> +switch ( bytes )
> +{
> +
>>> On 26.10.17 at 19:03, wrote:
> * invvpid has a 128-bit memory operand but we only require the VPID value
> which lies in the lower 64 bits.
The memory operand (wrongly) isn't being read at all - I don't
understand the above bullet point for that reason.
> @@ -464,6 +462,8 @@ static int dec
>>> On 26.10.17 at 19:03, wrote:
> hvm_copy_{to,from}_guest_virt() copy data to and from a guest, performing
> segmentatino and paging checks on the provided seg:offset virtual address.
I'm not sure "paging" is worthwhile to mention here, as that's not
done by the new functions, but by the existi
>>> On 27.11.17 at 19:08, wrote:
> On 27/11/17 17:01, Jan Beulich wrote:
>>>>> On 26.10.17 at 19:03, wrote:
>>> +return X86EMUL_OKAY;
>> This and ...
>>
>>> +}
>>> +else
>>> +{
>>> +pa
>>> On 26.10.17 at 19:03, wrote:
In the title please use "read/write" or "access".
> @@ -380,17 +383,7 @@ static int operand_read(void *buf, struct vmx_inst_op
> *op,
> return X86EMUL_OKAY;
> }
> else
> -{
> -pagefault_info_t pfinfo;
> -int rc = hvm_copy_f
>>> On 28.11.17 at 10:12, wrote:
> In theory the BIOS would search for address space and won't find
> anything, so the hotplug operation should fail even before it reaches
> the kernel in the first place.
How would the BIOS know what the OS does or plans to do? I think
it's the other way around
>>> On 28.11.17 at 10:49, wrote:
>> -Original Message-----
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 27 November 2017 08:29
>> To: xen-devel
>> Cc: Julien Grall ; Andrew Cooper
>> ; Paul Durrant
>> Subject: [PATCH] x
>>> On 28.11.17 at 11:05, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 28 November 2017 10:02
>> >>> On 28.11.17 at 10:49, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: 27 November 2017
>>> On 28.11.17 at 11:22, wrote:
> It would definitely be good to only reset io_completion when it is clear
> that handle_hvm_io_completion() is not going to be called (i.e. for
> internally handled I/O)
Where would you suggest to do that? These two ...
> and perhaps even add ASSERTs in _hvm_e
>>> On 28.11.17 at 11:17, wrote:
> Am 28.11.2017 um 10:46 schrieb Jan Beulich:
>>>>> On 28.11.17 at 10:12, wrote:
>>> In theory the BIOS would search for address space and won't find
>>> anything, so the hotplug operation should fail even b
>>> On 28.11.17 at 12:06, wrote:
> Yes, it appears that mmio_retry is only set when the underlying emulation
> returned X86EMUL_OKAY but not all reps were completed. If the underlying
> emulation did not return X86EMUL_RETRY then I can't figure out why
> vio->io_completion should need to be set
>>> On 28.11.17 at 12:32, wrote:
> I have a feeling that you can trigger this also when xen.efi
> is launched directly from EFI. However, this may require some
> fiddling with crashkernel values.
I don't think so, no - that case was specifically fixed already
(I've pointed at that commit in anoth
>>> On 28.11.17 at 12:58, wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Paul Durrant
>> Sent: 28 November 2017 11:31
>> To: 'Jan Beulich'
>> Cc: Andrew Cooper ;
>>> On 28.11.17 at 13:47, wrote:
> On Tue, Nov 28, 2017 at 04:51:51AM -0700, Jan Beulich wrote:
>> >>> On 28.11.17 at 12:32, wrote:
>> > I have a feeling that you can trigger this also when xen.efi
>> > is launched directly from EFI. However, this ma
>>> On 28.11.17 at 14:53, wrote:
> On Tue, Nov 28, 2017 at 06:37:17AM -0700, Jan Beulich wrote:
>> >>> On 28.11.17 at 13:47, wrote:
>> > Then all cases should be covered.
>>
>> I don't think that's going to be enough: Once Xen gets move
>>> On 28.11.17 at 13:41, wrote:
> On Mon, Nov 27, 2017 at 09:51:56AM -0700, Jan Beulich wrote:
>> >>> On 27.11.17 at 16:41, wrote:
>> > If it is possible we would like to have the Xen image higher than the
>> > booloader put it and certainly do no
>>> On 18.10.17 at 10:27, wrote:
> 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).
I
>>> On 18.10.17 at 10:27, wrote:
> New definitions provide a convenient way of accessing contents of
> VMX MSRs. They are separated into 5 logical blocks:
>
> 1. vmx: [VMX_BASIC, VMX_VMCS_ENUM]
> 2. VMX_PROCBASED_CTLS2
> 3. VMX_EPT_VPID_CAP
> 4. vmx_true_ctls: [VMX_TRUE_PINBASED_C
>>> On 18.10.17 at 10:27, wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -32,6 +32,37 @@ struct msr_domain_policy __read_mostly
> raw_msr_domain_policy,
> struct msr_vcpu_policy __read_mostly hvm_max_msr_vcpu_policy,
> __read_mostly pv_max_msr_vcpu
>>> On 18.10.17 at 10:27, wrote:
> +static void __init calculate_hvm_max_vmx_policy(struct msr_domain_policy *dp)
> +{
> +if ( !cpu_has_vmx )
> +return;
> +
> +dp->vmx.basic.raw = host_msr_domain_policy.vmx.basic.raw;
> +
> +dp->vmx.pinbased_ctls.raw = ((uint64_t) VMX_PINBASED_
lers.
>
> Signed-off-by: Sergey Dyasli
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 18.10.17 at 10:27, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -124,6 +124,7 @@ static int update_domain_cpuid_info(struct domain *d,
> }
>
> recalculate_cpuid_policy(d);
> +recalculate_domain_msr_policy(d);
Considering the name of the other func
>>> On 18.10.17 at 10:27, wrote:
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -360,8 +360,10 @@ int init_vcpu_msr_policy(struct vcpu *v)
>
> int guest_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
> {
> +const struct domain *d = v->domain;
> const struct msr_d
>>> On 28.11.17 at 19:06, wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -140,6 +140,20 @@ config XSM_POLICY
>
> If unsure, say Y.
>
> +config XSM_POLICY_OVERRIDE
> + bool "Built-in security policy overrides bootloader provided policy"
> + default n
This is
25ff028
> (XEN) Pagetable walk from 025ff028:
> ...
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>>> On 29.11.17 at 13:09, wrote:
> Modify Config.mk and Kconfig.debug to disable debug by default in
> preparation for late RCs and eventual release.
>
> Signed-off-by: Julien Grall
>
> ---
>
> I would like this to get included before branching. So we can cut the RC
> right after branching.
I
>>> On 29.11.17 at 15:13, wrote:
> --- a/tools/libxl/libxl_x86_acpi.c
> +++ b/tools/libxl/libxl_x86_acpi.c
> @@ -23,7 +23,6 @@
> /* Number of pages holding ACPI tables */
> #define NUM_ACPI_PAGES 16
> /* Store RSDP in the last 64 bytes of BIOS RO memory */
> -#define RSDP_ADDRESS (0x10 - 6
>>> On 29.11.17 at 15:22, wrote:
> On 11/29/2017 01:29 PM, Jan Beulich wrote:
>>>>> On 29.11.17 at 13:09, wrote:
>>> Modify Config.mk and Kconfig.debug to disable debug by default in
>>> preparation for late RCs and eventual release.
>>>
>>> On 29.11.17 at 16:08, wrote:
> On 11/9/2017 2:28 AM, Jan Beulich wrote:
>>>>> On 08.11.17 at 16:44, wrote:
>>> On 11/7/2017 8:40 AM, Jan Beulich wrote:
>>>>>>> On 06.11.17 at 18:48, wrote:
>>>>> --- a/Documentation/ABI/
>>> On 29.11.17 at 16:33, wrote:
> On Wed, Nov 29, 2017 at 1:19 AM, Jan Beulich wrote:
>>>>> On 28.11.17 at 19:06, wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>> @@ -140,6 +140,20 @@ config XSM_POLICY
>>>
&g
>>> On 29.11.17 at 16:38, wrote:
> The detection of ConditionVirtualisation= relies on the presence of
> /proc/xen/capabilities. If the file exists and contains the string
> "control_d", the running system is a dom0 and VIRTUALIZATION_NONE should
> be set. In case /proc/xen exists, or some sysfs f
>>> On 29.11.17 at 16:37, wrote:
> On 11/9/2017 2:49 AM, Jan Beulich wrote:
>>>>> On 09.11.17 at 00:06, wrote:
>>> +static int pcistub_reset_dev(struct pci_dev *dev)
>>> +{
>>> + struct xen_pcibk_dev_data *dev_data;
>>> +
>>> On 29.11.17 at 15:32, wrote:
> On 29/11/17 14:23, Jann Horn wrote:
>> gnttab_setup_table() has the following code:
>>
>> =
>> static long
>> gnttab_setup_table(
>> XEN_GUEST_HANDLE_PARAM(gnttab_setup_table_t) uop, unsigned int count)
>> {
>>
>>> On 29.11.17 at 16:54, wrote:
> On Wed, Nov 29, Jan Beulich wrote:
>
>> With all of the above, was it considered to check /sys/hypervisor
>> alongside with or perhaps even in preference to /proc/xen?
>
> Yes.
> /proc/xen/capabilities is the one and only
>>> On 29.11.17 at 17:07, wrote:
> On Wed, Nov 29, Jan Beulich wrote:
>
>> But in the description you talk about detect_vm() - by its name that
>> doesn't look to care about Dom0, but whether running on top of
>> _some_ hypervisor.
>
> dom0 has to
>>> On 29.11.17 at 17:29, wrote:
> On Wed, Nov 29, 2017 at 08:35:33AM -0700, Jan Beulich wrote:
>> >>> On 29.11.17 at 16:08, wrote:
>> > On 11/9/2017 2:28 AM, Jan Beulich wrote:
>> >>>>> On 08.11.17 at 16:44, wrote:
>> >>>
>>> On 29.11.17 at 19:56, wrote:
> On Tue, Nov 28, 2017 at 07:28:25AM -0700, Jan Beulich wrote:
>> Another option is to consider not moving Xen based on other
>> criteria: The main goal here is to free up memory below 16Mb. If
>> the machine has no memory above 16Mb,
>>> On 29.11.17 at 18:38, wrote:
>>> In the case of bus or slot reset, our goal is to reset connected PCIe
>>> fabric/card/endpoint.
>>> The connected card/endpoint can be multi-function device. So, same
>>> walk-through and checking
>>> is needed irrespective of type of reset being used.
>> I don
>>> On 29.11.17 at 20:44, wrote:
> So, we will use the following sequence to reset the requested
> device/function.
>
> - FLR (as first option)
> - BUS/SLOT reset (as fall-back option) if FLR is not supported or any
> issue with FLR
It looks to me as if the slot reset could also fail despite t
>>> On 30.11.17 at 09:23, wrote:
> On Wed, Nov 29, Jan Beulich wrote:
>
>> Ah, I see. But then still I don't see why at least on half way
>> recent Xen /sys/hypervisor/properties/features wouldn't have
>> the information you're after (and eve
ble() should turn off shadow mode if no other bit
besides PG_SH_enable remains set (just like shadow_one_bit_enable()
enables it if not already set), or the domain pausing scope should be
extended so that both steps occur without the domain getting a chance to
run in between.
Reported-by: Olaf Herin
>>> On 30.11.17 at 10:10, wrote:
> Olaf has observed this assertion to trigger after an aborted migration
> of a PV guest (it remains to be determined why there is a page fault in
> the first place here:
>
> (XEN) Xen call trace:
> (XEN)[] do_page_fault+0x39f/0x55c
> (XEN)[] x86_64/entry.
>>> On 30.11.17 at 12:33, wrote:
> On 30/11/17 09:10, Jan Beulich wrote:
>> Olaf has observed this assertion to trigger after an aborted migration
>> of a PV guest (it remains to be determined why there is a page fault in
>> the first place here:
>&
1: correct GNTTABOP_cache_flush empty batch handling
2: improve GNTTABOP_cache_flush locking
Compile tested only, as this is being used by ARM only. I'd therefore
appreciate an ARM person to take a close look and/or try it out.
Signed-off-by: Jan Be
there will be no result to pick
> up. Hence it bogus to request such completion when mmio_retry is set,
> since this can only happen if the underlying I/O emulation has returned
> X86EMUL_OKAY (meaning the I/O has completed successfully).
>
> Reported-by: Andrew Cooper
> Signed-off
t the order of argument checks:
We shouldn't accept zero-length elements with unknown bits set in "op".
Also constify cache_flush()'s first parameter.
Reported-by: Jann Horn
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_t
Dropping the lock before returning from grant_map_exists() means handing
possibly stale information back to the caller. Return back the pointer
to the active entry instead, for the caller to release the lock once
done.
Signed-off-by: Jan Beulich
--- a/xen/common/grant_table.c
+++ b/xen/common
>>> On 30.11.17 at 15:15, wrote:
> On 11/30/2017 2:27 AM, Jan Beulich wrote:
>>>>> On 29.11.17 at 18:38, wrote:
>>>>> In the case of bus or slot reset, our goal is to reset connected PCIe
>>>>> fabric/card/endpoint.
>>>>
>>> On 30.11.17 at 19:54, wrote:
> On 27/11/17 14:41, Jan Beulich wrote:
>>>>> On 27.11.17 at 14:02, wrote:
>>> Xen 4.8 and later virtualises CPUID Faulting support for guests. However,
> the
>>> value of MSR_MISC_FEATURES_ENABLES is omitted f
>>> On 01.12.17 at 11:21, wrote:
> On Thu, Nov 30, 2017 at 01:35:45AM -0700, Jan Beulich wrote:
>> >>> On 30.11.17 at 09:23, wrote:
>> > On Wed, Nov 29, Jan Beulich wrote:
>> >
>> >> Ah, I see. But then still I don't see why at
>>> On 01.12.17 at 12:48, wrote:
> Suppose at one point we split hardware domain and control domain, which
> one will you call Dom0? Which one will get the flag?
There can only be one hardware domain, which will continue to
be the one getting XENFEAT_dom0. There could be any number
of control dom
>>> On 01.12.17 at 13:15, wrote:
> On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote:
>> >>> On 01.12.17 at 12:48, wrote:
>> > Suppose at one point we split hardware domain and control domain, which
>> > one will you call Dom0? Which one wi
>>> On 30.11.17 at 20:32, wrote:
> List,
> this XSA-245 appears in the xen-devel ML, but unlike XSA-246,247 it never
> appears in the git logs.
> Was it ever committed?
Yes. Did you perhaps scan for "XSA-245" in the description, which
may have been omitted in this case?
Jan
__
>>> Wei Liu 12/01/17 1:30 PM >>>
>On Fri, Dec 01, 2017 at 05:23:16AM -0700, Jan Beulich wrote:
>> >>> On 01.12.17 at 13:15, wrote:
>> > On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote:
>> >> >>> On 01.12.17 at 12:48,
1 - 100 of 29623 matches
Mail list logo
