>>> On 02.05.17 at 19:37, wrote:
> On 02/05/17 10:43, Tim Deegan wrote:
>> At 02:50 -0600 on 02 May (1493693403), Jan Beulich wrote:
>> On 02.05.17 at 10:32, wrote:
At 04:52 -0600 on 28 Apr (1493355160), Jan Beulich wrote:
On 27.04.17 at 11:51, wrote:
>> At 03:23 -0600 on 2
>>> On 02.05.17 at 18:54, wrote:
> On 02/05/17 16:31, Jan Beulich wrote:
> On 02.05.17 at 17:15, wrote:
>>> get_page() logs a message when it fails (dom_cow is never dying or
>>> paging_mode_external()), so better avoid the call when it's pointless
>>> to do anyway.
>>>
>>> Signed-off-by: Jan
>>> On 02.05.17 at 19:04, wrote:
> On 02/05/17 16:15, Jan Beulich wrote:
>> get_page() logs a message when it fails (dom_cow is never dying or
>> paging_mode_external()), so better avoid the call when it's pointless
>> to do anyway.
>>
>> Signed-off-by: Jan Beulich
>
> The other option would be
>>> On 04.05.17 at 00:15, wrote:
> 'commit 1679e0df3df6 ("x86/ioreq server: asynchronously reset
> outstanding p2m_ioreq_server entries")' will call
> p2m_change_entry_type_global() which set entry.recalc=1. Then
> the following get_entry(p2m_ioreq_server) will return
> p2m_ram_rw type.
> But 'com
>>> On 02.05.17 at 20:05, wrote:
> The backlink field doesn't exist in a 64bit TSS, and union for esp{0..2} is of
> no practical use. Specify everything with stdint types, and empty bitfields
> for reserved values.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Be
flight 71248 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71248/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like
71233
test-amd64-i
>>> On 02.05.17 at 20:05, wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -645,6 +645,14 @@ void load_system_tables(void)
> tss->ist[IST_DF - 1] = stack_top + IST_DF * PAGE_SIZE;
> tss->ist[IST_NMI - 1] = stack_top + IST_NMI * PAGE_SIZE;
>
> + /*
>>> On 02.05.17 at 20:05, wrote:
> As originally reported, the Linear Pagetable slot maps 512GB of ram as RWX,
> where the guest has full read access and a lot of direct or indirect control
> over the written content. It isn't hard for a PV guest to hide shellcode
> here.
>
> Therefore, increase
This patch moves 'cpuid_count_leaf' from cpuid.c to processor.h to
make it available to external codes.
Signed-off-by: Yi Sun
Acked-by: Jan Beulich
---
v9:
- create this patch alone to move 'cpuid_count_leaf'.
(suggested by Wei Liu)
v6:
- use 'struct cpuid_leaf' in psr.c. So we hav
Hi all,
We plan to bring a new PSR (Platform Shared Resource) feature called
Intel L2 Cache Allocation Technology (L2 CAT) to Xen. It has been enabled
in Linux Kernel.
Besides the L2 CAT implementaion, we refactor the psr.c to make it more
flexible and easily to extend to add new features. We abs
The current cache allocation codes in psr.c do not consider
future features addition and are not friendly to extend.
To make psr.c be more flexible to add new features and fulfill
the program principle, open for extension but closed for
modification, we have to refactor the psr.c:
1. Analyze cache
This patch creates CAT and CDP feature document in doc/features/. It describes
key points to implement L3 CAT/CDP and L2 CAT which is described in details in
Intel SDM "INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION
FEATURES".
Signed-off-by: Yi Sun
Reviewed-by: Konrad Rzeszutek Wilk
As set value flow is the most complicated one in psr, it will be
divided to some patches to make things clearer. This patch
implements the set value framework to show a whole picture firstly.
It also changes domctl interface to make it more general.
To make the set value flow be general and can s
Only can one COS ID be used by one domain at one time. That means all enabled
features' COS registers at this COS ID are valid for this domain at that time.
When user updates a feature's value, we need make sure all other features'
values are not affected. So, we firstly need gather an array which
Continue from previous patch:
'x86: refactor psr: L3 CAT: set value: implement cos finding flow.'
If fail to find a COS ID, we need pick a new COS ID for domain. Only COS ID
that ref[COS_ID] is 1 or 0 can be picked to input a new set feature values.
Signed-off-by: Yi Sun
---
v11:
- remove un
This patch implements the CPU init flow for CDP. The flow is almost
same as L3 CAT.
Signed-off-by: Yi Sun
---
v11:
- changes about 'feat_props'.
(suggested by Jan Beulich)
- remove MSR restore action which is unnecessary.
(suggested by Jan Beulich)
- modify commit message.
This patch implements the CPU init flow for L2 CAT.
Signed-off-by: Yi Sun
---
v11:
- move l2 cat 'type[]' assignement into 'psr_cpu_init'.
- remove COS MSR restore action in 'cpu_init_feature'.
- set 'feat_init' to true after CPU init.
- modify commit message.
v10:
- implement
This patch implements L2 CAT get value interface in domctl.
Signed-off-by: Yi Sun
---
v11:
- remove "get_val' assignment because it has been replaced by generic
codes.
(suggested by Jan Beulich)
v10:
- remove cast in domctl.
(suggested by Jan Beulich)
v9:
- reuse 'ca
This patch implements L3 CDP set value related callback function.
With this patch, 'psr-cat-cbm-set' command can work for L3 CDP.
Signed-off-by: Yi Sun
---
v11:
- move 'feat->cos_reg_val' assignment and value comparison in 'write_msr'
callback function out as generic codes.
(sugg
This patch adds L2 CAT description in related documents.
Signed-off-by: He Chen
Signed-off-by: Yi Sun
Acked-by: Wei Liu
---
docs/man/xl.pod.1.in | 25 ++---
docs/misc/xl-psr.markdown | 18 --
2 files changed, 34 insertions(+), 9 deletions(-)
diff --git
Continue from patch:
'x86: refactor psr: L3 CAT: set value: assemble features value array'
We can try to find if there is a COS ID on which all features' COS registers
values are same as the array assembled before.
Signed-off-by: Yi Sun
---
v11:
- move 'compare_val' implementation from CDP p
This patch implements get HW info flow for CDP including L3 CDP callback
function. The flow is almost same as L3 CAT.
With this patch, 'psr-hwinfo' can work for L3 CDP.
Signed-off-by: Yi Sun
---
v11:
- modify 'psr_get_info' flow to make it simple to cover CDP case.
v10:
- update renamed
This patch implements get HW info flow including L3 CAT callback
function.
It also changes sysctl interface to make it more general.
With this patch, 'psr-hwinfo' can work for L3 CAT.
Signed-off-by: Yi Sun
---
v11:
- changes about 'cos_max' and 'cbm_len'.
(suggested by Jan Beulich)
This patch implements L2 CAT get HW info flow and interface in sysctl.
Signed-off-by: Yi Sun
---
v10:
- modify macro name according to previous patch change.
(suggested by Jan Beulich)
- modify commit message.
v9:
- reuse 'cat_get_feat_info' for L2 CAT to reduce redundant codes.
This patch implements L2 CAT set value related callback function
and domctl interface.
Signed-off-by: Yi Sun
---
v11:
- remove 'domctl->u.psr_cat_op.data' check because it has been moved into
'psr_set_val'.
(suggested by Jan Beulich)
- move 'feat->cos_reg_val' assignment and v
To construct an extendible framework, we need analyze PSR features
and abstract the common things and feature specific things. Then,
encapsulate them into different data structures.
By analyzing PSR features, we can get below map.
+--+--+--+
->| Dom0 | Dom
Continue from previous patch:
'x86: refactor psr: L3 CAT: set value: implement cos id picking flow.'
We have got the feature value and COS ID to set. Then, we write MSRs of the
designated feature.
Till now, set value process is completed.
Signed-off-by: Yi Sun
---
v11:
- rename 'write_psr_m
This patch implements the Domain init/free and schedule flows.
- When domain init, its psr resource should be allocated.
- When domain free, its psr resource should be freed too.
- When domain is scheduled, its COS ID on the socket should be
set into ASSOC register to make corresponding COS MSR v
This patch implements the xl/xc changes to support set CBM
for L2 CAT.
The new level option is introduced to original CAT setting
command in order to set CBM for specified level CAT.
- 'xl psr-cat-set' is updated to set cache capacity bitmasks(CBM)
for a domain according to input cache level.
r
This patch implements xl/xc changes to support get HW info
for L2 CAT.
'xl psr-hwinfo' is updated to show both L3 CAT and L2 CAT
info.
Example(on machine which only supports L2 CAT):
Cache Monitoring Technology (CMT):
Enabled : 0
Cache Allocation Technology (CAT): L2
Socket ID : 0
M
This patch implements changes in xl/xc changes to support
showing CBM of L2 CAT.
The new level option is introduced to original CAT showing
command in order to show CBM for specified level CAT.
- 'xl psr-cat-show' is updated to show CBM of a domain
according to input cache level.
Examples:
root
There is an interface in user space to show feature value of
domains.
This patch implements get value flow in hypervisor.
It also changes domctl interface to make it more general.
With this patch, 'psr-cat-show' can work for L3 CAT but not for
L3 code/data which is implemented in CDP related pat
On 03/05/2017 02:08, Stefano Stabellini wrote:
> The Xen mapcache is able to create long term mappings, they are called
> "locked" mappings. The third parameter of the xen_map_cache call
> specifies if a mapping is a "locked" mapping.
>
>
> From the QEMU point of view there are two kinds of lon
>>> On 02.05.17 at 20:05, wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -3872,7 +3872,7 @@ void __init trap_init(void)
>
> /* The 32-on-64 hypercall vector is only accessible from ring 1. */
> _set_gate(idt_table + HYPERCALL_VECTOR,
> - SYS_DESC_tra
>>> On 02.05.17 at 20:05, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/pv/traps.c
> @@ -0,0 +1,44 @@
> +/**
> + * arch/x86/pv/traps.c
> + *
> + * PV low level entry points.
> + *
> + * This program is free software; you can
>>> On 02.05.17 at 20:05, wrote:
> With its sole other user removed, fold LOAD_C_CLOBBERED into RESTORE_ALL to
> reduce the cognitive load of trying to work out which registers get
> modified.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
This small series first creates hvm/vm_event.{h,c}, in order to bring
under vm_event maintainership the code that has previously lived in
hvm_do_resume(), and then fixes a __context_switch()-related race
condition when attempting to set registers via vm_event reply.
Previously this has been a sing
The introspection agent can reply to a vm_event faster than
vmx_vmexit_handler() can complete in some cases, where it is then
not safe for vm_event_set_registers() to modify v->arch.user_regs.
In the test scenario, we were stepping over an INT3 breakpoint by
setting RIP += 1. The quick reply tended
Created arch/x86/hvm/vm_event.c and include/asm-x86/hvm/vm_event.h,
where HVM-specific vm_event-related code will live. This cleans up
hvm_do_resume() and ensures that the vm_event maintainers are
responsible for changes to that code.
Signed-off-by: Razvan Cojocaru
---
MAINTAINERS
> >>> On 04.05.17 at 00:15, wrote:
> > 'commit 1679e0df3df6 ("x86/ioreq server: asynchronously reset
> > outstanding p2m_ioreq_server entries")' will call
> > p2m_change_entry_type_global() which set entry.recalc=1. Then
> > the following get_entry(p2m_ioreq_server) will return
> > p2m_ram_rw type
>>> On 02.05.17 at 20:05, wrote:
> @@ -366,6 +367,16 @@ static always_inline void stac(void)
> LOAD_ONE_REG(bp, \compat)
> LOAD_ONE_REG(bx, \compat)
> subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp
> +.if \compat
> +xor %r8d, %r8d
> +xor %r9d, %r9d
> +
At 00:31 -0600 on 03 May (1493771502), Jan Beulich wrote:
> Hmm, with both of you being of that opinion, I've taken another
> look. I think I see now why you think that way (this being data
> from an internal producer, overflow/underflow are not a primary
> concern), so I'll withdraw my objection t
On 05/03/17 12:15, Tim Deegan wrote:
> At 00:31 -0600 on 03 May (1493771502), Jan Beulich wrote:
>> Hmm, with both of you being of that opinion, I've taken another
>> look. I think I see now why you think that way (this being data
>> from an internal producer, overflow/underflow are not a primary
>
At 10:15 +0100 on 03 May (1493806508), Tim Deegan wrote:
> At 00:31 -0600 on 03 May (1493771502), Jan Beulich wrote:
> > +else if ( ctxt.cur > sizeof(*desc) )
> > {
> > uint32_t off;
> > -const struct hvm_save_descriptor *desc;
> >
> > -rv = -ENOENT;
> >
flight 108141 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/108141/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs.
107236
Regression
>>> On 03.05.17 at 11:21, wrote:
> At 10:15 +0100 on 03 May (1493806508), Tim Deegan wrote:
>> At 00:31 -0600 on 03 May (1493771502), Jan Beulich wrote:
>> > +else if ( ctxt.cur > sizeof(*desc) )
>> > {
>> > uint32_t off;
>> > -const struct hvm_save_descriptor *desc;
>> >
On Tue, May 02, 2017 at 07:05:22PM +0100, Andrew Cooper wrote:
> As originally reported, the Linear Pagetable slot maps 512GB of ram as RWX,
> where the guest has full read access and a lot of direct or indirect control
> over the written content. It isn't hard for a PV guest to hide shellcode
> h
Hi Jan,
On 02/05/17 16:43, Jan Beulich wrote:
On 02.05.17 at 17:21, wrote:
hvm_save_cpu_ctxt() returns success without writing any data into
hvm_domain_context_t when all VCPUs are offline. This can then crash
the hypervisor (with FATAL PAGE FAULT) in hvm_save_one() via the
"off < (ctxt.cur -
On Tue, May 02, 2017 at 07:05:25PM +0100, Andrew Cooper wrote:
> With its sole other user removed, fold LOAD_C_CLOBBERED into RESTORE_ALL to
> reduce the cognitive load of trying to work out which registers get modified.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: We
On Tue, May 02, 2017 at 07:05:20PM +0100, Andrew Cooper wrote:
> The backlink field doesn't exist in a 64bit TSS, and union for esp{0..2} is of
> no practical use. Specify everything with stdint types, and empty bitfields
> for reserved values.
>
> No functional change.
>
> Signed-off-by: Andrew
>>> On 03.05.17 at 11:10, wrote:
> @@ -483,67 +483,7 @@ void hvm_do_resume(struct vcpu *v)
> if ( !handle_hvm_io_completion(v) )
> return;
>
> -if ( unlikely(v->arch.vm_event) )
> -{
> -struct monitor_write_data *w = &v->arch.vm_event->write_data;
> -
> -if
On 03/05/17 08:21, Jan Beulich wrote:
On 02.05.17 at 19:37, wrote:
>> On 02/05/17 10:43, Tim Deegan wrote:
>>> At 02:50 -0600 on 02 May (1493693403), Jan Beulich wrote:
>>> On 02.05.17 at 10:32, wrote:
> At 04:52 -0600 on 28 Apr (1493355160), Jan Beulich wrote:
> On 27.04.17
flight 108151 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/108151/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 5 xen-buildfail REGR. vs. 107636
build-arm64
>>> On 03.05.17 at 11:10, wrote:
> The introspection agent can reply to a vm_event faster than
> vmx_vmexit_handler() can complete in some cases, where it is then
> not safe for vm_event_set_registers() to modify v->arch.user_regs.
> In the test scenario, we were stepping over an INT3 breakpoint b
On 02/05/17 06:45, Chao Gao wrote:
> On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote:
>> On 26/04/17 01:52, Chao Gao wrote:
>>> I compared the maximum of #entry in one list and #event (adding entry to
>>> PI blocking list) with and without the three latter patches. Here
>>> is the res
Hi,
At 19:05 +0100 on 02 May (1493751922), Andrew Cooper wrote:
> As originally reported, the Linear Pagetable slot maps 512GB of ram as RWX,
> where the guest has full read access and a lot of direct or indirect control
> over the written content. It isn't hard for a PV guest to hide shellcode
>
Hi Bhupinder,
Title: Please avoid the term pfn and use gfn or mfn.
On 28/04/17 17:01, Bhupinder Thakur wrote:
1. Add two new domctl API to:
- Allocate a new event channel for sending/receiving events to/from Xen.
- Map the PFN allocted by the toolstack to be used as IN/OUT ring buffers.
>>> On 03.05.17 at 12:08, wrote:
> On 02/05/17 06:45, Chao Gao wrote:
>> On Wed, Apr 26, 2017 at 05:39:57PM +0100, George Dunlap wrote:
>>> On 26/04/17 01:52, Chao Gao wrote:
I compared the maximum of #entry in one list and #event (adding entry to
PI blocking list) with and without the t
On 02/05/17 16:23, Julien Grall wrote:
Hi Bhupinder,
On 02/05/17 16:20, Bhupinder Thakur wrote:
Hi Jan,
@@ -631,6 +632,9 @@ int arch_domain_create(struct domain *d,
unsigned int domcr_flags,
if ( (rc = domain_vtimer_init(d, config)) != 0 )
goto fail;
+if ( domcr_flags & D
Hi Bhupinder,
On 28/04/17 17:01, Bhupinder Thakur wrote:
An option is provided in libxl to enable/disable pl011 vuart while
creating a guest domain.
Libxl now suppots a generic vuart console and pl011 is a specific type.
s/supports/supports/
In future support can be added for multiple vuart
CC Ian
On Wed, May 03, 2017 at 03:04:44AM +0300, Reinis Martinsons wrote:
> Hi,
>
> I would like to report a problem with storage driver domain. When detaching
> 2 virtual block devices from the same domain provided by the same driver
> domain, this generates a segmentation fault in the driver do
On 05/03/17 12:51, Jan Beulich wrote:
On 03.05.17 at 11:10, wrote:
>> @@ -483,67 +483,7 @@ void hvm_do_resume(struct vcpu *v)
>> if ( !handle_hvm_io_completion(v) )
>> return;
>>
>> -if ( unlikely(v->arch.vm_event) )
>> -{
>> -struct monitor_write_data *w = &v-
Hi Bhupinder,
On 28/04/17 17:01, Bhupinder Thakur wrote:
The SBSA uart node format is as specified in
Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt and given below:
ARM SBSA defined generic UART
--
This UART uses a subset of the PL011 registers and conse
On 05/03/17 13:01, Jan Beulich wrote:
On 03.05.17 at 11:10, wrote:
>> The introspection agent can reply to a vm_event faster than
>> vmx_vmexit_handler() can complete in some cases, where it is then
>> not safe for vm_event_set_registers() to modify v->arch.user_regs.
>> In the test scenario,
On 05/03/17 12:30, Jan Beulich wrote:
On 03.05.17 at 11:21, wrote:
>> At 10:15 +0100 on 03 May (1493806508), Tim Deegan wrote:
>>> At 00:31 -0600 on 03 May (1493771502), Jan Beulich wrote:
+else if ( ctxt.cur > sizeof(*desc) )
{
uint32_t off;
-con
flight 108139 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/108139/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 17 guest-start/win.repeat fail REGR.
vs. 107900
Tests w
Just wanted to give this a little nudge now people seem to be back on
deck...
On 01/05/17 10:55, Glenn Enright wrote:
> On 19/04/17 22:09, Juergen Gross wrote:
>> On 19/04/17 09:16, Roger Pau Monné wrote:
>>> On Wed, Apr 19, 2017 at 06:39:41AM +0200, Juergen Gross wrote:
On 19/04/17 03:02, Gl
>>> On 03.05.17 at 12:22, wrote:
>
> On 02/05/17 16:23, Julien Grall wrote:
>> Hi Bhupinder,
>>
>> On 02/05/17 16:20, Bhupinder Thakur wrote:
>>> Hi Jan,
>>>
> @@ -631,6 +632,9 @@ int arch_domain_create(struct domain *d,
> unsigned int domcr_flags,
> if ( (rc = domain_vtimer_ini
>>> On 03.05.17 at 12:37, wrote:
> On 05/03/17 12:51, Jan Beulich wrote:
> On 03.05.17 at 11:10, wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/x86/hvm/vm_event.c
>>> @@ -0,0 +1,101 @@
>>> +/*
>>> + * arch/x86/hvm/vm_event.c
>>> + *
>>> + * HVM vm_event handling routines
>>> + *
>>> + * Copyrigh
flight 108180 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/108180/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen ba10dbc7ae6c92816109913c6c25ba66c7aa7288
baseline version:
xen ba39
Hi,
>> > It looks like you are reusing the libxl__device_console_add call for the
>> > main PV console for the domain, to also add the vuart nodes to xenstore.
>> >
>> > I don't think it is a good idea to mix the two. I suggest to introduce a
>> > new libxl__device call to introduce the vuart node
On 02/05/17 19:05, Andrew Cooper wrote:
> As originally reported, the Linear Pagetable slot maps 512GB of ram as RWX,
> where the guest has full read access and a lot of direct or indirect control
> over the written content. It isn't hard for a PV guest to hide shellcode
> here.
>
> Therefore, in
On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote:
> >>> On 02.05.17 at 20:05, wrote:
> > --- /dev/null
> > +++ b/xen/arch/x86/pv/traps.c
> > @@ -0,0 +1,44 @@
> > +/**
> > + * arch/x86/pv/traps.c
> > + *
> > + *
On 03/05/17 12:26, Wei Liu wrote:
> On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote:
> On 02.05.17 at 20:05, wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/x86/pv/traps.c
>>> @@ -0,0 +1,44 @@
>>> +/**
>>> + *
On Wed, May 03, 2017 at 12:38:15PM +0100, Andrew Cooper wrote:
> On 03/05/17 12:26, Wei Liu wrote:
> > On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote:
> > On 02.05.17 at 20:05, wrote:
> >>> --- /dev/null
> >>> +++ b/xen/arch/x86/pv/traps.c
> >>> @@ -0,0 +1,44 @@
> >>> +/**
>>> On 03.05.17 at 13:26, wrote:
> On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote:
>> >>> On 02.05.17 at 20:05, wrote:
>> > --- /dev/null
>> > +++ b/xen/arch/x86/pv/traps.c
>> > @@ -0,0 +1,44 @@
>> >
> +/***
> *
On 03/05/17 11:44, Razvan Cojocaru wrote:
> On 05/03/17 12:30, Jan Beulich wrote:
> On 03.05.17 at 11:21, wrote:
>>> At 10:15 +0100 on 03 May (1493806508), Tim Deegan wrote:
At 00:31 -0600 on 03 May (1493771502), Jan Beulich wrote:
> +else if ( ctxt.cur > sizeof(*desc) )
>
>>> On 03.05.17 at 13:38, wrote:
> On 03/05/17 12:26, Wei Liu wrote:
>> On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote:
>> On 02.05.17 at 20:05, wrote:
--- /dev/null
+++ b/xen/arch/x86/pv/traps.c
@@ -0,0 +1,44 @@
> +/**
>>> On 03.05.17 at 14:00, wrote:
> On 03/05/17 11:44, Razvan Cojocaru wrote:
>> On 05/03/17 12:30, Jan Beulich wrote:
>> On 03.05.17 at 11:21, wrote:
At 10:15 +0100 on 03 May (1493806508), Tim Deegan wrote:
> At 00:31 -0600 on 03 May (1493771502), Jan Beulich wrote:
>> +else
On 03/05/17 13:02, Jan Beulich wrote:
On 03.05.17 at 13:38, wrote:
>> On 03/05/17 12:26, Wei Liu wrote:
>>> On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote:
>>> On 02.05.17 at 20:05, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/pv/traps.c
> @@ -0,0 +1,44 @@
>
>
hvm_save_cpu_ctxt() returns success without writing any data into
hvm_domain_context_t when all VCPUs are offline. This can then crash
the hypervisor (with FATAL PAGE FAULT) in hvm_save_one() via the
"off < (ctxt.cur - sizeof(*desc))" for() test, where ctxt.cur remains 0,
causing an underflow which
On 03/05/17 09:10, Jan Beulich wrote:
On 02.05.17 at 20:05, wrote:
>> The backlink field doesn't exist in a 64bit TSS, and union for esp{0..2} is
>> of
>> no practical use. Specify everything with stdint types, and empty bitfields
>> for reserved values.
>>
>> No functional change.
>>
>> Si
>>> On 03.05.17 at 14:18, wrote:
> On 03/05/17 13:02, Jan Beulich wrote:
> On 03.05.17 at 13:38, wrote:
>>> On 03/05/17 12:26, Wei Liu wrote:
On Wed, May 03, 2017 at 03:02:25AM -0600, Jan Beulich wrote:
On 02.05.17 at 20:05, wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86
Hi Roger,
Sorry for the late answer.
On 15/03/17 17:00, Roger Pau Monn? wrote:
On Wed, Mar 15, 2017 at 11:54:07AM -0500, Venu Busireddy wrote:
On Wed, Mar 15, 2017 at 04:38:39PM +, Roger Pau Monn? wrote:
On Wed, Mar 15, 2017 at 10:11:35AM -0500, Venu Busireddy wrote:
On Wed, Mar 15, 2017
On 05/03/17 15:22, Jan Beulich wrote:
> hvm_save_cpu_ctxt() returns success without writing any data into
> hvm_domain_context_t when all VCPUs are offline. This can then crash
> the hypervisor (with FATAL PAGE FAULT) in hvm_save_one() via the
> "off < (ctxt.cur - sizeof(*desc))" for() test, where
On 03/05/17 09:14, Jan Beulich wrote:
On 02.05.17 at 20:05, wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -645,6 +645,14 @@ void load_system_tables(void)
>> tss->ist[IST_DF - 1] = stack_top + IST_DF * PAGE_SIZE;
>> tss->ist[IST_NMI - 1] = stack
On 03/05/17 13:45, Razvan Cojocaru wrote:
> On 05/03/17 15:22, Jan Beulich wrote:
>> hvm_save_cpu_ctxt() returns success without writing any data into
>> hvm_domain_context_t when all VCPUs are offline. This can then crash
>> the hypervisor (with FATAL PAGE FAULT) in hvm_save_one() via the
>> "off
Hi Roger,
On 15/03/17 16:38, Roger Pau Monn? wrote:
On Wed, Mar 15, 2017 at 10:11:35AM -0500, Venu Busireddy wrote:
On Wed, Mar 15, 2017 at 12:56:50PM +, Roger Pau Monn? wrote:
On Wed, Mar 15, 2017 at 08:42:04AM -0400, Konrad Rzeszutek Wilk wrote:
On Wed, Mar 15, 2017 at 12:07:28PM +,
This is for additional defence-in-depth following LDT/GDT/IDT corruption.
It causes attempted control transfers to ring 1 or 2 (via a call gate), or
attempts to use IST 3 through 7 to yield #SS, rather than executing with a
stack starting at the top of virtual address space.
Express the TSS setup
On 03/05/17 12:45, Steven Haigh wrote:
> Just wanted to give this a little nudge now people seem to be back on
> deck...
Things seem to be more complicated than I thought.
There are clearly paths leading to use-after-free scenarios, e.g. the
one of the backtrace below:
xen_blkbk_remove() will fr
On 03/05/17 09:49, Jan Beulich wrote:
On 02.05.17 at 20:05, wrote:
>> As originally reported, the Linear Pagetable slot maps 512GB of ram as RWX,
>> where the guest has full read access and a lot of direct or indirect control
>> over the written content. It isn't hard for a PV guest to hide
On 03/05/17 09:55, Jan Beulich wrote:
On 02.05.17 at 20:05, wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -3872,7 +3872,7 @@ void __init trap_init(void)
>>
>> /* The 32-on-64 hypercall vector is only accessible from ring 1. */
>> _set_gate(idt_table + HY
>>> On 03.05.17 at 15:29, wrote:
> This is for additional defence-in-depth following LDT/GDT/IDT corruption.
>
> It causes attempted control transfers to ring 1 or 2 (via a call gate), or
> attempts to use IST 3 through 7 to yield #SS, rather than executing with a
> stack starting at the top of v
>>> On 03.05.17 at 15:38, wrote:
> My method of working out which areas to change were to consider all uses
> of __PAGE_HYPERVISOR. I have half a mind to submit a change renaming it
> to __PAGE_PGTABLE, as it should only really be used to build
> intermediate pagetable entries where we control X/
Is there a reason why we don't document hypervisor time leaf (3, or is
it 4?) in public/arch-x86/cpuid.h?
We have a regression in Linux where there is a window when
vcpu_time_info data is not yet available and one possibility is to use
this leaf. But I'd like to be sure it is part of a stable ABI.
On 03/05/17 14:57, Boris Ostrovsky wrote:
> Is there a reason why we don't document hypervisor time leaf (3, or is
> it 4?) in public/arch-x86/cpuid.h?
(The leaf with the number 3. The way the documentation refers to leaves
and numeric values is very counter-intuitive. I half remember a plan to
On 05/03/2017 10:06 AM, Andrew Cooper wrote:
> On 03/05/17 14:57, Boris Ostrovsky wrote:
>> Is there a reason why we don't document hypervisor time leaf (3, or is
>> it 4?) in public/arch-x86/cpuid.h?
> (The leaf with the number 3. The way the documentation refers to leaves
> and numeric values is
On Wed, May 03, 2017 at 04:27:41PM +0300, Reinis Martinsons wrote:
> On 03.05.2017 13:27, Wei Liu wrote:
> libxl: debug: libxl_linux.c:200:libxl__get_hotplug_script_info: num_exec 1,
> not running hotplug scripts
> libxl: debug: libxl_device.c:1143:device_hotplug: No hotplug script to execute
> li
>>> On 03.05.17 at 16:06, wrote:
> On 03/05/17 14:57, Boris Ostrovsky wrote:
>> Is there a reason why we don't document hypervisor time leaf (3, or is
>> it 4?) in public/arch-x86/cpuid.h?
>
> (The leaf with the number 3. The way the documentation refers to leaves
> and numeric values is very co
>>> On 03.05.17 at 16:26, wrote:
> Looking at __update_vcpu_system_time(), I am not sure we are reporting
> correct values on (PV & !vtsc). I think it should be t->tsc_scale.
Indeed. I wouldn't be surprised at all if it was simply assumed by
the author to only be used by HVM guests. And the issue
1 - 100 of 159 matches
Mail list logo
