On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> xen_smp_intr_init() and xen_smp_intr_free() have PV-specific code and as
> a praparatory change to splitting smp.c we need to split these fucntions.
> Create xen_smp_intr_init_pv()/xen_smp_intr_free_pv().
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-b
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> Split xen_smp_prepare_boot_cpu() into xen_pv_smp_prepare_boot_cpu() and
> xen_hvm_smp_prepare_boot_cpu() to support further splitting of smp.c.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Juergen Gross
Juergen
___
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> Split xen_cpu_die() into xen_pv_cpu_die() and xen_hvm_cpu_die() to support
> further splitting of smp.c.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> Move PVHVM related code to smp_hvm.c. Drop 'static' qualifier from
> xen_smp_send_reschedule(), xen_smp_send_call_function_ipi(),
> xen_smp_send_call_function_single_ipi(), these functions will be moved to
> common smp code when smp_pv.c is split.
>
> S
flight 106625 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106625/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
flight 106628 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106628/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 5 xen-install fail REGR. vs. 106608
Regressions which are r
> -Original Message-
> From: Igor Druzhinin
> Sent: 10 March 2017 20:07
> To: sstabell...@kernel.org; Anthony Perard
> Cc: Paul Durrant ; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Igor Druzhinin
> Subject: [PATCH v2] xen: don't save/restore the physmap on VM
> save/restore
On Fri 10-03-17 12:39:27, Yasuaki Ishimatsu wrote:
> On 03/10/2017 08:58 AM, Michal Hocko wrote:
[...]
> >OK so I did with -m 2G,slots=4,maxmem=4G -numa node,mem=1G -numa node,mem=1G
> >which generated
> >[...]
> >[0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009]
> >[0.00
On Fri 10-03-17 13:00:37, Reza Arbab wrote:
> On Fri, Mar 10, 2017 at 04:53:33PM +0100, Michal Hocko wrote:
> >OK, so while I was playing with this setup some more I probably got why
> >this is done this way. All new memblocks are added to the zone Normal
> >where they are accounted as spanned but
On Tue, Mar 07, 2017 at 03:26:52PM +, Andrew Cooper wrote:
> ./xtf-runner wants to distinguish between a clean and unclean exits of the
> test. OSSTest doesn't care, so map unclean exit to failure.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
_
>>> On 10.03.17 at 18:22, wrote:
> On 08.03.2017 13:54, Jan Beulich wrote:
>> All,
>>
>> I am pleased to announce the release of Xen 4.6.5. This is
>> available immediately from its git repository
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.6
>> (tag RELEASE-4.6.
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> Basically, smp.c is renamed to smp_pv.c and some code moved out to common
> smp.c. struct xen_common_irq delcaration ended up in smp.h.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Juergen Gross
Juergen
___
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> Move PVHVM related code to mmu_hvm.c.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> Basically, mmu.c is renamed to mmu_pv.c and some code moved out to common
> mmu.c.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.or
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> startup_xen references PV-only code, decorate it with #ifdef CONFIG_XEN_PV
> to make PV-free builds possible.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> __pfn_to_mfn() is only used from PV code (mmu_pv.c, p2m.c) and from
> page.h where all functions calling it check for
> xen_feature(XENFEAT_auto_translated_physmap) first so we can replace
> it with any stub to make build happy.
>
> set_foreign_p2m_mapp
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> Balloon driver uses several PV-only concepts (xen_start_info,
> xen_extra_mem,..) and it seems the simpliest solution to make HVM-only
> build happy is to decorate these parts with #ifdefs.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Juergen Gros
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> xen_create_contiguous_region()/xen_create_contiguous_region() are PV-only,
> they both contain xen_feature(XENFEAT_auto_translated_physmap) check and
> bail in the very beginning.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Juergen Gross
Juerg
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> Now everything is in place and we can move PV-only code under
> CONFIG_XEN_PV. CONFIG_XEN_PV_SMP is created to support the change.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Juergen Gross
Juergen
On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> After code split between PV and HVM some functions in xen_smp_ops have
> xen_pv_ prefix and some only xen_ which makes them look like they're
> common for both PV and HVM while they're not. Rename all the rest to
> have xen_pv_ prefix.
>
> Signed-off-by
flight 106629 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106629/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
test-amd64-i386-xl-qemuu-
On 13/03/17 09:24, Jan Beulich wrote:
On 10.03.17 at 18:22, wrote:
>> On 08.03.2017 13:54, Jan Beulich wrote:
>>> All,
>>>
>>> I am pleased to announce the release of Xen 4.6.5. This is
>>> available immediately from its git repository
>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h
On Fri, 10 Mar 2017 14:58:07 +0100
Michal Hocko wrote:
> Let's CC people touching this logic. A short summary is that onlining
> memory via udev is currently unusable for online_movable because blocks
> are added from lower addresses while movable blocks are allowed from
> last blocks. More below
A typo was made in 7a6de259f.
Currently libxlutil lives in the same directory as libxl, fixing this
issue causes no functional change.
Signed-off-by: Wei Liu
---
tools/Rules.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/Rules.mk b/tools/Rules.mk
index e676c6b665..
On Mon 13-03-17 11:31:10, Igor Mammedov wrote:
> On Fri, 10 Mar 2017 14:58:07 +0100
[...]
> > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009]
> > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x0010-0x3fff]
> > [0.00] ACPI: SRAT: Node 1 PXM 1 [mem 0x4000-0x7ff
On 13.03.2017 11:29, Andrew Cooper wrote:
> On 13/03/17 09:24, Jan Beulich wrote:
> On 10.03.17 at 18:22, wrote:
>>> On 08.03.2017 13:54, Jan Beulich wrote:
All,
I am pleased to announce the release of Xen 4.6.5. This is
available immediately from its git repository
ht
Hello Saurav
On Mon, Mar 06, 2017 at 03:50:37PM +, Saurav Sachidanand wrote:
> Hello,
>
> I'm Saurav Sachidanand, and I'm a CS sophomore studying in India. For
> more than year I've been programming in Rust and have published some
> personal projects in it (few involving the Rust-C FFI) and h
Currently xen always sets the shadow VMCS-indicator bit on nested
vmptrld and always clears it on nested vmclear. This behavior is
wrong when the guest loads a shadow VMCS: shadow bit will be lost
on nested vmclear.
Fix this by checking if the guest has provided a shadow VMCS.
Signed-off-by: Ser
Intel SDM states that if there is a current VMCS and there is MOV-SS
blocking, VMFailValid occurs and control passes to the next instruction.
Implement such behaviour for nested vmlaunch and vmresume.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vvmx.c| 16
xen
This series includes 2 more checks for nested vmentry and a fix for
handling a nested shadow vmcs.
Sergey Dyasli (3):
x86/vvmx: add mov-ss blocking check to vmentry
x86/vvmx: correct nested shadow VMCS handling
x86/vvmx: add a shadow vmcs check to vmlaunch
xen/arch/x86/hvm/vmx/vvmx.c
Intel SDM states that if the current VMCS is a shadow VMCS,
VMFailInvalid occurs and control passes to the next instruction.
Implement such behaviour for nested vmlaunch.
Signed-off-by: Sergey Dyasli
---
xen/arch/x86/hvm/vmx/vvmx.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/xen/
On Mon, Mar 13, 2017 at 10:47:08AM +, Wei Liu wrote:
> Hello Saurav
>
> On Mon, Mar 06, 2017 at 03:50:37PM +, Saurav Sachidanand wrote:
> > Hello,
> >
> > I'm Saurav Sachidanand, and I'm a CS sophomore studying in India. For
> > more than year I've been programming in Rust and have publis
We want to add HCR_EL2 register to Xen context switch. And each copy
of HCR_EL2 in vcpu structure will be initialized with the same set
of trap flags as the HCR_EL2 register. We introduce a helper here to
represent these flags to be reused easily.
Signed-off-by: Wei Chen
---
xen/arch/arm/traps.c
Different domains may have different HCR_EL2 flags. For example, the
64-bit domain needs HCR_RW flag but the 32-bit does not need it. So
we give each domain a default HCR_EL2 value and save it in the VCPU's
context.
HCR_EL2 register has only one bit can be updated automatically without
explicit wr
On Thu, 9 Mar 2017 13:54:00 +0100
Michal Hocko wrote:
[...]
> > It's major regression if you remove auto online in kernels that
> > run on top of x86 kvm/vmware hypervisors, making API cleanups
> > while breaking useful functionality doesn't make sense.
> >
> > I would ACK config option removal
Xen will do exception syndrome check while some types of exception
take place in EL2. The syndrome check code read the ESR_EL2 register
directly, but in some situation this register maybe overridden by
nested exception.
For example, if we re-enable IRQ before reading ESR_EL2 which means
Xen will e
From XSA-201 (see [1]), we know that, a guest could trigger SErrors when
accessing memory mapped HW in a non-conventional way. In the patches for
XSA-201, we crash the guest when we captured such asynchronous aborts to
avoid data corruption.
In order to distinguish guest-generated SErrors from hyp
The HCR_EL2.VSE (HCR.VA for aarch32) bit can be used to generate a
virtual abort to guest. The HCR_EL2.VSE bit has a peculiar feature
of getting cleared when the guest has taken the abort (this is the
only bit that behaves as such in HCR_EL2 register).
This means that if we set the HCR_EL2.VSE bit
In the later patches of this series, we want to use the alternative
patching framework to avoid checking serror_op in every entries.
So we define a new cpu feature "SKIP_CHECK_PENDING_VSERROR" for
serror_op. When serror_op is not equal to SERROR_DIVERSE, this
feature will be set to cpu_hwcaps.
But
In order to distinguish guest-generated SErrors from hypervisor-generated
SErrors. We have to place SError checking code in every EL1 -> EL2 paths.
That will be an overhead on entries caused by dsb/isb.
But not all platforms want to categorize the SErrors. For example, a host
that is running with
When guest triggers async aborts, in most platform, such aborts
will be routed to hypervisor. But we don't want the hypervisor
to handle such aborts, so we have to route such aborts back to
the guest.
This helper is using the HCR_EL2.VSE (HCR.VA for aarch32) bit to
route such aborts back to the gu
The HCR_EL2 flags for 64-bit and 32-bit domains are different. But
when we initialized the HCR_EL2 for vcpu0 of Dom0 and all vcpus of
DomU in vcpu_initialise, we didn't know the domain's address size
information. We had to use compatible flags to initialize HCR_EL2,
and set HCR_RW for 64-bit domain
We want to move part of SErrors checking code from hyp_error assembly code
to a function. This new function will use this macro to distinguish the
guest SErrors from hypervisor SErrors. So we have to move this macro to
common header.
Signed-off-by: Wei Chen
---
xen/arch/arm/arm64/entry.S
We have provided an option to administrator to determine how to
handle the SErrors. In order to skip the check of pending SError,
in conventional way, we have to read the option every time before
we try to check the pending SError.
Currently, we haven't export the option to other source file. But,
1: fold exit paths
2: centralize put_fpu() invocations
3: correct handling of FPU insns faulting on memory write
4: correct FPU code/data pointers and opcode handling
XTF: add FPU/SIMD register state test
Signed-off-by: Jan Beulich
___
Xen-devel maili
Currently, we masked the Abort/SError bit in Xen exception entries.
So Xen could not capture any Abort/SError while it's running.
Now, Xen has the ability to handle the Abort/SError, we should unmask
the Abort/SError bit by default to let Xen capture Abort/SError while
it's running.
But in order t
If there is a pending SError while we are doing context switch, if the
SError handle option is "FORWARD", We have to guranatee this serror to
be caught by current vCPU, otherwise it will be caught by next vCPU and
be forwarded to this wrong vCPU.
We don't want to export serror_op accessing to othe
Currently, ARM32 and ARM64 has different SError exception handlers.
These handlers include lots of code to check SError handle options
and code to distinguish guest-generated SErrors from hypervisor
SErrors.
The new helpers: do_trap_guest_serror and do_trap_hyp_serror are
wrappers of __do_trap_ser
We have provided an option to administrator to determine how to
handle the SErrors. In order to skip the check of pending SError,
in conventional way, we have to read the option every time before
we try to check the pending SError. This will add overhead to check
the option at every trap.
The ARM6
If there is a pending SError while we're returning from trap. If the
SError handle option is "DIVERSE", we have to prevent slipping this
hypervisor SError to guest. So we have to use the dsb/isb to guarantee
that the pending hypervisor SError would be caught in hypervisor before
return to guest.
S
We may have to isolate the SError between the context switch of
2 vCPUs or may have to prevent slipping hypervisor SError to guest.
So we need a helper to synchronize SError before context switching
or returning to guest.
This function will be used by the later patches in this series, we
use "#if
We have introduced two helpers to handle the guest/hyp SErrors:
do_trap_guest_serror and do_trap_guest_hyp_serror. These handlers
can take the role of do_trap_guest_serror and reduce the assembly
code in the same time. So we use these two helpers to replace it
and drop it now.
Signed-off-by: Wei C
The guest generated external data/instruction aborts can be treated
as guest SErrors. We already have a handler to handle the SErrors,
so we can reuse this handler to handle guest external aborts.
Signed-off-by: Wei Chen
---
xen/arch/arm/traps.c | 14 ++
1 file changed, 6 insertions(
On 13/03/17 10:51, Sergey Dyasli wrote:
> Intel SDM states that if there is a current VMCS and there is MOV-SS
> blocking, VMFailValid occurs and control passes to the next instruction.
>
> Implement such behaviour for nested vmlaunch and vmresume.
>
> Signed-off-by: Sergey Dyasli
The content her
>>> On 13.03.17 at 11:29, wrote:
> On 13/03/17 09:24, Jan Beulich wrote:
> On 10.03.17 at 18:22, wrote:
>>> On 08.03.2017 13:54, Jan Beulich wrote:
All,
I am pleased to announce the release of Xen 4.6.5. This is
available immediately from its git repository
http://xen
Move "cannot_emulate" and make it go through the common (error) exit
path.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -7762,7 +7762,9 @@ x86_emulate(
}
default:
-goto cannot_emulate;
+cannot_emul
..., splitting parts of it into check_*() macros. This is in
preparation of making ->put_fpu() do further adjustments to register
state. (Some of the check_xmm() invocations could be avoided, as in
some of the cases no insns handled there can actually raise #XM, but I
think we're better off keeping
When an FPU instruction with a memory destination fails during the
memory write, it should not affect FPU register state. Due to the way
we emulate FPU (and SIMD) instructions, we can only guarantee this by
- backing out changes to the FPU register state in such a case or
- doing a descriptor read
Prevent leaking the hypervisor ones (stored by hardware during stub
execution), at once making sure the guest sees correct values there.
This piggybacks on the backout logic used to deal with write faults of
FPU insns.
Deliberately ignore the NO_FPU_SEL feature here: Honoring it would
merely mean
Add tests to verify that
- FPU insns leave correct (guest) values in FIP/FDP/FOP/FCS/FDS,
- FPU insns writing memory don't update FPU register state when the
write faults (at the example of FISTP),
- VCVTPS2PH (once implemented in the emulator) doesn't update MXCSR
if its write faults (VCVTPS2P
Hi Felix
Thanks for your interest in this project.
On Sun, Mar 12, 2017 at 09:48:11PM +0100, Felix Ekkehard Schmoll wrote:
> Hi,
>
> I’m interested in the “Fuzzing Xen hypercall interface” project so I
> just wanted to introduce myself:
>
> I’m a third-year undergraduate CS student at Jacobs Un
>>> On 11.03.17 at 09:42, wrote:
> On 3/10/2017 11:29 PM, Jan Beulich wrote:
> On 08.03.17 at 16:33, wrote:
>>> changes in v7:
>>>- Use new ioreq server interface - XEN_DMOP_map_mem_type_to_ioreq_server.
>>>- According to comments from George: removed domain_pause/unpause() in
>>>
On 13/03/17 10:59, Jan Beulich wrote:
On 13.03.17 at 11:29, wrote:
>> On 13/03/17 09:24, Jan Beulich wrote:
>> On 10.03.17 at 18:22, wrote:
On 08.03.2017 13:54, Jan Beulich wrote:
> All,
>
> I am pleased to announce the release of Xen 4.6.5. This is
> available immed
>>> On 11.03.17 at 09:42, wrote:
> On 3/10/2017 11:33 PM, Jan Beulich wrote:
> On 08.03.17 at 16:33, wrote:
>>> @@ -197,6 +217,10 @@ static int hvmemul_do_io(
>>>* - If the IOREQ_MEM_ACCESS_WRITE flag is not set, treat it
>>>* like a normal PIO or MMIO that doesn't
>>> On 11.03.17 at 09:42, wrote:
> On 3/11/2017 12:03 AM, Jan Beulich wrote:
>> But there's a wider understanding issue I'm having here: What is
>> an "entry" here? Commonly I would assume this to refer to an
>> individual (4k) page, but it looks like you really mean table entry,
>> i.e. possibly
>>> On 11.03.17 at 09:42, wrote:
> On 3/11/2017 12:17 AM, Jan Beulich wrote:
> On 08.03.17 at 16:33, wrote:
>>> --- a/xen/include/asm-x86/p2m.h
>>> +++ b/xen/include/asm-x86/p2m.h
>>> @@ -611,6 +611,11 @@ void p2m_change_type_range(struct domain *d,
>>> int p2m_change_type_one(struct domain
On 13/03/17 11:03, Jan Beulich wrote:
> Move "cannot_emulate" and make it go through the common (error) exit
> path.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen
>>> On 11.03.17 at 09:42, wrote:
> On 3/11/2017 12:59 AM, Andrew Cooper wrote:
>> On 08/03/17 15:33, Yu Zhang wrote:
>>> --- a/xen/arch/x86/hvm/dm.c
>>> +++ b/xen/arch/x86/hvm/dm.c
>>> @@ -288,6 +288,7 @@ static int inject_event(struct domain *d,
>>> return 0;
>>> }
>>>
>>> +#define DMO
>>> On 13.03.17 at 06:12, wrote:
> I'm confusing about the behavior of HLT instruction in VMX guest mode.
>
> I set "hlt exiting" bit to 0 in VMCS, and the vcpu didn't vmexit when execute
> HLT as expected. However, I used powertop/cpupower on host to watch the pcpu's
> c-states, it seems that th
From: Vijaya Kumar K
On ARM, virt_to_mfn uses the hardware for address
translation. So if the virtual address is not mapped translation
fault is raised.On ARM, DIRECTMAP_VIRT region is direct mapped.
On ARM with NUMA, While initializing second memory node,
panic is triggered from init_node_heap(
>>> On 13.03.17 at 12:22, wrote:
> On 13/03/17 10:59, Jan Beulich wrote:
> On 13.03.17 at 11:29, wrote:
>>> On 13/03/17 09:24, Jan Beulich wrote:
>>> On 10.03.17 at 18:22, wrote:
> On 08.03.2017 13:54, Jan Beulich wrote:
>> All,
>>
>> I am pleased to announce the release
flight 106627 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106627/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-cubietruck 16 guest-start.2fail pass in 106605
Regressions which are regarded a
>>> On 10.03.17 at 18:10, wrote:
> On 28/02/17 09:31, Jan Beulich wrote:
> On 27.02.17 at 16:10, wrote:
>>> On 22/02/17 10:10, Jan Beulich wrote:
>>> On 22.02.17 at 11:00, wrote:
> On 22/02/17 09:23, Jan Beulich wrote:
> On 20.02.17 at 12:00, wrote:
>>> The domain builde
>>> On 10.03.17 at 18:36, wrote:
> 2017-03-10 23:03 GMT+08:00 Jan Beulich :
> On 09.03.17 at 04:13, wrote:
>>> If CMDLINE is set, the cmdline_parse() routine will append the bootloader
>>> command line to this string, forming the complete command line
>>> before parsing.
>>
>> I disagree to m
On 13/03/17 11:03, Jan Beulich wrote:
> ..., splitting parts of it into check_*() macros. This is in
> preparation of making ->put_fpu() do further adjustments to register
> state. (Some of the check_xmm() invocations could be avoided, as in
> some of the cases no insns handled there can actually r
On 03/10/2017 09:01 PM, Tamas K Lengyel wrote:
> On Fri, Mar 10, 2017 at 4:21 AM, Andrew Cooper
> wrote:
>> On 10/03/17 07:34, Jan Beulich wrote:
>> On 09.03.17 at 18:29, wrote:
On Thu, Mar 9, 2017 at 9:56 AM, Jan Beulich wrote:
> However - is this interface supposed to be usable by
>>> On 10.03.17 at 17:27, wrote:
> Leaf 0x4 is reserved by AMD. For Intel, it is a multi-invocation leaf with
> ecx enumerating different cache details.
>
> Add a new union for it in struct cpuid_policy, collect it from hardware in
> calculate_raw_policy(), audit it in recalculate_cpuid_policy()
>>> On 10.03.17 at 17:32, wrote:
> The thermal/performance leaf was previously hidden from HVM guests, but fully
> visible to PV guests. Most of the leaf refers to MSR availability, and there
> is nothing an unprivileged PV guest can do with the information, so hide the
> leaf entirely.
>
> Sign
>>> On 10.03.17 at 17:44, wrote:
> @@ -938,6 +927,21 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
> }
> break;
>
> +case 0xb:
> +/*
> + * In principle, this leaf is Intel-only. In practice, it is tightly
> + * coupled with x2apic, and we
>>> On 13.03.17 at 13:01, wrote:
> On 03/10/2017 09:01 PM, Tamas K Lengyel wrote:
>> On Fri, Mar 10, 2017 at 4:21 AM, Andrew Cooper
>> wrote:
>>> On 10/03/17 07:34, Jan Beulich wrote:
>>> On 09.03.17 at 18:29, wrote:
> On Thu, Mar 9, 2017 at 9:56 AM, Jan Beulich wrote:
>> However -
On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
> On Thu, 9 Mar 2017 13:54:00 +0100
> Michal Hocko wrote:
>
> [...]
> > > It's major regression if you remove auto online in kernels that
> > > run on top of x86 kvm/vmware hypervisors, making API cleanups
> > > while breaking useful functionality do
On 03/13/2017 02:19 PM, Jan Beulich wrote:
On 13.03.17 at 13:01, wrote:
>> On 03/10/2017 09:01 PM, Tamas K Lengyel wrote:
>>> On Fri, Mar 10, 2017 at 4:21 AM, Andrew Cooper
>>> wrote:
On 10/03/17 07:34, Jan Beulich wrote:
On 09.03.17 at 18:29, wrote:
>> On Thu, Mar 9, 2017
>>> On 13.03.17 at 12:55, wrote:
> On 13/03/17 11:03, Jan Beulich wrote:
>> @@ -1006,22 +1007,31 @@ do {
>> rc = _get_fpu(_type, _fic, ctxt, ops); \
>> if ( rc ) goto done;\
>> } while (0)
>> -#define _put_fpu()
>>> On 13.03.17 at 03:36, wrote:
> On 17-03-10 02:09:55, Jan Beulich wrote:
>> >>> On 10.03.17 at 03:54, wrote:
>> > On 17-03-08 09:07:10, Jan Beulich wrote:
>> >> >>> On 15.02.17 at 09:49, wrote:
>> >> > +ref[old_cos]--;
>> >> > +spin_unlock(&info->ref_lock);
>> >> > +
>> >> > +/*
>
>>> On 13.03.17 at 03:43, wrote:
> On 17-03-10 02:15:20, Jan Beulich wrote:
>> >>> On 10.03.17 at 04:21, wrote:
>> > On 17-03-08 09:54:04, Jan Beulich wrote:
>> >> >>> On 15.02.17 at 09:49, wrote:
>> >> > @@ -207,6 +233,29 @@ static enum psr_feat_type
> psr_cbm_type_to_feat_type(enum cbm_type t
>>> On 13.03.17 at 13:29, wrote:
> On 03/13/2017 02:19 PM, Jan Beulich wrote:
>> I think as long as there's no need for the guest to use an operation
>> on itself, it should not be a hvmop. After all, if you make it a domctl
>> now and later find a need for it to be called by the guest, we can
>>
On 03/13/2017 02:40 PM, Jan Beulich wrote:
On 13.03.17 at 13:29, wrote:
>> On 03/13/2017 02:19 PM, Jan Beulich wrote:
>>> I think as long as there's no need for the guest to use an operation
>>> on itself, it should not be a hvmop. After all, if you make it a domctl
>>> now and later find a n
On 13/03/17 12:03, Jan Beulich wrote:
On 10.03.17 at 17:27, wrote:
>> Leaf 0x4 is reserved by AMD. For Intel, it is a multi-invocation leaf with
>> ecx enumerating different cache details.
>>
>> Add a new union for it in struct cpuid_policy, collect it from hardware in
>> calculate_raw_polic
Michal Hocko writes:
> On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
>> > >
>> > >- suggested RFC is not acceptable from virt point of view
>> > > as it regresses guests on top of x86 kvm/vmware which
>> > > both use ACPI based memory hotplug.
>> > >
>> > >- u
Boris Ostrovsky writes:
> On 03/02/2017 12:53 PM, Vitaly Kuznetsov wrote:
>> Changes since v1:
>> - Patches 1,2 and 3 were split and reordered to avoid adding temporary
>>#ifdefs [Juergen Gross]
>> - Juergen's R-b added to what is now patches 14 and 15 (patches 4 and 5
>>in v1). Due to re
>>> On 13.03.17 at 13:51, wrote:
> On 13/03/17 12:03, Jan Beulich wrote:
> On 10.03.17 at 17:27, wrote:
>>> @@ -242,6 +243,25 @@ static void __init calculate_raw_policy(void)
>>> cpuid_leaf(i, &p->basic.raw[i]);
>>> }
>>>
>>> +if ( p->basic.max_leaf >= 4 )
>>> +{
>>> +
On 03/11/2017 08:06 AM, Andrew Cooper wrote:
> On 11/03/2017 03:58, Boris Ostrovsky wrote:
>> On 03/10/2017 09:39 PM, Boris Ostrovsky wrote:
>>> I am looking into GDT remap series [0] which crashes PV guests and it
>>> seems that the problem lies in the fact that we cannot establish new
>>> mapping
On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote:
> Michal Hocko writes:
>
> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
> >> > >
> >> > >- suggested RFC is not acceptable from virt point of view
> >> > > as it regresses guests on top of x86 kvm/vmware which
> >> > >
On 13/03/17 13:05, Jan Beulich wrote:
On 13.03.17 at 13:51, wrote:
>> On 13/03/17 12:03, Jan Beulich wrote:
>> On 10.03.17 at 17:27, wrote:
@@ -242,6 +243,25 @@ static void __init calculate_raw_policy(void)
cpuid_leaf(i, &p->basic.raw[i]);
}
+
>>> On 13.03.17 at 14:24, wrote:
> On 13/03/17 13:05, Jan Beulich wrote:
> On 13.03.17 at 13:51, wrote:
>>> On 13/03/17 12:03, Jan Beulich wrote:
>>> On 10.03.17 at 17:27, wrote:
> @@ -242,6 +243,25 @@ static void __init calculate_raw_policy(void)
> cpuid_leaf(i, &p->bas
Michal Hocko writes:
> On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote:
>> Michal Hocko writes:
>>
>> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
>> >> > >
>> >> > >- suggested RFC is not acceptable from virt point of view
>> >> > > as it regresses guests on top of x86 k
>>> On 13.03.17 at 12:43, wrote:
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -260,6 +260,13 @@ static inline int gvirt_to_maddr(vaddr_t va, paddr_t
> *pa, unsigned int flags)
> #define virt_to_mfn(va) (virt_to_maddr(va) >> PAGE_SHIFT)
> #define mfn_to_virt(mfn) (ma
On Mon, 13 Mar 2017 11:43:02 +0100
Michal Hocko wrote:
> On Mon 13-03-17 11:31:10, Igor Mammedov wrote:
> > On Fri, 10 Mar 2017 14:58:07 +0100
> [...]
> > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x-0x0009]
> > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x0010-0x3f
On 13/03/17 11:05, Jan Beulich wrote:
> When an FPU instruction with a memory destination fails during the
> memory write, it should not affect FPU register state. Due to the way
> we emulate FPU (and SIMD) instructions, we can only guarantee this by
> - backing out changes to the FPU register stat
On Mon 13-03-17 14:42:37, Vitaly Kuznetsov wrote:
> Michal Hocko writes:
>
> > On Mon 13-03-17 13:54:59, Vitaly Kuznetsov wrote:
> >> Michal Hocko writes:
> >>
> >> > On Mon 13-03-17 11:55:54, Igor Mammedov wrote:
> >> >> > >
> >> >> > >- suggested RFC is not acceptable from virt point
1 - 100 of 163 matches
Mail list logo
