On 09/09/16 18:18, Jennifer Herbert wrote:
> QEMU XenServer/XenProject Working group meeting 30th August 2016
>
...
> XenStore
>
>
> The xs-restrict mechanism was summarised, and its limitation – it does
> not work though th
>>> On 09.09.16 at 20:35, wrote:
> On 08/09/16 14:04, Jan Beulich wrote:
>> @@ -607,7 +609,7 @@ do{ asm volatile (
>> })
>> #define truncate_ea(ea) truncate_word((ea), ad_bytes)
>>
>> -#define mode_64bit() (def_ad_bytes == 8)
>> +#define mode_64bit() (ctxt->addr_size == 64)
>>
>> #define fa
flight 100888 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100888/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e9fec7326ad2f27fe368c830da055d1044b18e95
baseline version:
ovmf acc3a3776dc3fb3dc9008
>>> On 09.09.16 at 18:32, wrote:
> Would that sound reasonable - am I overlooking something? To some extent this
> might also applicable to the general case, although platform timer is now only
> used for initial seeding so probably a non-visible issue.
Wouldn't it already help to simply make TSC
>>> On 12.09.16 at 05:26, wrote:
> On 16-09-09 02:32:25, Jan Beulich wrote:
>> >>> On 09.09.16 at 10:09, wrote:
>> > First time, user wants to set L3 CAT of Dom1 to 0x1ff for example. The
>> > old_cos
>> > of Dom1 is 0. L3 CAT is the first element of feature list. The COS
>> > registers
>> > va
>>> On 11.09.16 at 22:35, wrote:
> As compared to x86 the va of the hypervisor .text
> is locked down - we cannot modify the running pagetables
> to have the .ro flag unset. We borrow the same idea that
> alternative patching has - which is to vmap the entire
> .text region and use the alternative
>>> On 11.09.16 at 22:35, wrote:
> The patch piggybacks on: livepatch: Initial ARM64 support, which
> brings up all of the neccessary livepatch infrastructure pieces in.
>
> This patch adds three major pieces:
>
> 1) ELF relocations. ARM32 uses SHT_REL instead of SHT_RELA which
> means the
>>> On 11.09.16 at 17:48, wrote:
> --- a/docs/misc/livepatch.markdown
> +++ b/docs/misc/livepatch.markdown
> @@ -875,6 +875,12 @@ section and the new function will reference the new
> string in the new
>
> This is implemented in the Xen Project hypervisor.
>
> +Note that the .bss section is
>>> On 11.09.16 at 17:48, wrote:
> The initial patch: 11ff40fa7bb5fdcc69a58d0fec49c904ffca4793
> "xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op" caps the
> size of the binary at 2MB. We follow that in capping the size
> of the .BSSes to be at maximum 2MB.
>
> Signed-off-by: Konrad Rzes
On 16-09-12 01:30:22, Jan Beulich wrote:
> >>> On 12.09.16 at 05:26, wrote:
> > On 16-09-09 02:32:25, Jan Beulich wrote:
> >> >>> On 09.09.16 at 10:09, wrote:
> >> > First time, user wants to set L3 CAT of Dom1 to 0x1ff for example. The
> >> > old_cos
> >> > of Dom1 is 0. L3 CAT is the first ele
> From: Xuquan (Euler) [mailto:xuqu...@huawei.com]
> Sent: Friday, September 09, 2016 11:02 AM
>
> On August 30, 2016 1:58 PM, Tian Kevin < kevin.t...@intel.com > wrote:
> >> From: Xuquan (Euler) [mailto:xuqu...@huawei.com]
> >> Sent: Friday, August 19, 2016 8:59 PM
> >>
> >> When Xen apicv is ena
>>> On 11.09.16 at 17:48, wrote:
> The NOP functionality will NOP any of the code at
> the 'old_addr' or at 'name' if the 'new_addr' is zero.
> The purpose of this is to NOP out calls, such as:
>
> e8 <4-bytes-offset>
>
> (5 byte insn), or on ARM a 4 byte insn for branching.
>
> We need the EI
This patch cleaned up the code by replacing complicated tlbflush check with
an inline function. We should use this inline function to avoid the long
and complicated to read tlbflush check when implementing TODOs left in
commit a902c12ee45fc9389eb8fe54eeddaf267a555c58.
Signed-off-by: Dongli Zhang
flight 100887 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100887/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-qcow2 6 xen-boot fail pass in 100884
Regressions which are regarded a
This patch implemented parts of TODO left in commit id
a902c12ee45fc9389eb8fe54eeddaf267a555c58. It moved TLB-flush filtering out
into populate_physmap. Because of TLB-flush in alloc_heap_pages, it's very
slow to create a guest with memory size of more than 100GB on host with
100+ cpus.
This patch
Clang identifies:
multi.c:82:23: error: use of GNU 'missing =' extension in
designator [-Werror,-Wgnu-designator]
[ft_prefetch] "prefetch",
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Tim Deegan
CC: George Dunlap
---
xen/arch/x86/mm/shadow/multi.
Hello Sergej,
On 16/08/2016 23:16, Sergej Proskurin wrote:
Signed-off-by: Sergej Proskurin
Acked-by: Julien Grall
Regards,
---
Cc: Stefano Stabellini
Cc: Julien Grall
---
v2: Cosmetic fixes.
v3: Cosmetic fixes.
Renamed the function "altp2m_init_next" to
"altp2m_init_next_avail
At 09:34 +0100 on 12 Sep (1473672846), Andrew Cooper wrote:
> Clang identifies:
>
> multi.c:82:23: error: use of GNU 'missing =' extension in
> designator [-Werror,-Wgnu-designator]
> [ft_prefetch] "prefetch",
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: T
Hello Sergej,
On 16/08/2016 23:16, Sergej Proskurin wrote:
Signed-off-by: Sergej Proskurin
---
Cc: Stefano Stabellini
Cc: Julien Grall
---
v2: Substituted the call to tlb_flush for p2m_flush_table.
Added comments.
Cosmetic fixes.
v3: Changed the locking mechanism to "p2m_write_lock"
On Fri, Sep 09, 2016 at 10:20:40AM -0500, Doug Goldstein wrote:
> On 9/8/16 11:21 AM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Sep 08, 2016 at 06:45:36AM -0600, Jan Beulich wrote:
> >> Commit 6ea24e53f1 introduced two problems: It left out a semicolon and
> >> typo-ed the source file name of the EF
Hello Sergej,
On 16/08/2016 23:16, Sergej Proskurin wrote:
Signed-off-by: Sergej Proskurin
---
Cc: Stefano Stabellini
Cc: Julien Grall
---
v3: Extended the function "altp2m_switch_domain_altp2m_by_id" so that if
the guest domain indirectly calles this function, the current vcpu also
c
Hello,
c/s 350bc1a9d4 "x86: support newer Intel CPU models" changed the set of
MSRs read by Xeon Broadwell hardware (specifically, model 79 / 0x47).
Rereading the manual, it does indeed indicate that this MSR is available.
However, experimentally it is not. All Broadwell hardware XenServer has
Hello Sergej,
On 16/08/2016 23:16, Sergej Proskurin wrote:
This commit adapts the function "p2m_restore_state" in a way that the
currently active altp2m table is considered during state restoration.
Signed-off-by: Sergej Proskurin
Acked-by: Julien Grall
Regards,
---
Cc: Stefano Stabellin
On 09/09/16 11:00, Wei Liu wrote:
> On Thu, Sep 08, 2016 at 09:20:25AM +0200, Juergen Gross wrote:
>> Add HVM usb passthrough support to libxl by using qemu's capability
>> to emulate standard USB controllers.
>>
>> A USB controller is added via qmp command to the emulated hardware
>> when a usbctr
Hello Sergej,
On 16/08/2016 23:16, Sergej Proskurin wrote:
This commit introduces the macro "p2m_get_active_p2m" returning the
currently active (alt)p2m. The need for this macro will be shown in the
following commits.
Signed-off-by: Sergej Proskurin
Acked-by: Julien Grall
Regards,
---
Cc
Hello Sergej,
On 16/08/2016 23:16, Sergej Proskurin wrote:
This commit extends the function prototypes of the functions:
* __p2m_get_mem_access
* p2m_mem_access_check_and_get_page
We extend the function prototype of "__p2m_get_mem_access" to hold an
argument of type "struct p2m_domain*", as we
Hello Sergej,
On 16/08/2016 23:17, Sergej Proskurin wrote:
This commit extends the function "p2m_mem_access_check" and
"p2m_mem_access_check_and_get_page" to consider altp2m. The function
"p2m_mem_access_check_and_get_page" needs to translate the gva upon the
hostp2m's vttbr, as it contains all
>>> On 12.09.16 at 10:47, wrote:
> c/s 350bc1a9d4 "x86: support newer Intel CPU models" changed the set of
> MSRs read by Xeon Broadwell hardware (specifically, model 79 / 0x47).
>
> Rereading the manual, it does indeed indicate that this MSR is available.
>
> However, experimentally it is not.
Hello Sergej,
On 16/08/2016 23:17, Sergej Proskurin wrote:
This commit introduces the following functions:
* remove_altp2m_entry
* modify_altp2m_entry
These functions are responsible to manage an altp2m view's entries and
their attributes.
Signed-off-by: Sergej Proskurin
---
Cc: Stefano Stabe
On September 12, 2016 3:58 PM, Tian, Kevin wrote:
>> From: Xuquan (Euler) [mailto:xuqu...@huawei.com]
>> Sent: Friday, September 09, 2016 11:02 AM
>>
>> On August 30, 2016 1:58 PM, Tian Kevin < kevin.t...@intel.com > wrote:
>> >> From: Xuquan (Euler) [mailto:xuqu...@huawei.com]
>> >> Sent: Friday,
Hello Sergej,
On 16/08/2016 23:17, Sergej Proskurin wrote:
The function "p2m_lookup_attr" allows to lookup the mfn, memory type,
access rights, and page order corresponding to a domain's gfn.
Signed-off-by: Sergej Proskurin
---
Cc: Stefano Stabellini
Cc: Julien Grall
---
v3: Change function
Hello Sergej,
On 16/08/2016 23:17, Sergej Proskurin wrote:
This commit makes sure that the page reference count is updated through
the function "p2m_put_l3_page" only the entries have been freed from the
hosts's p2m.
Signed-off-by: Sergej Proskurin
---
Cc: Stefano Stabellini
Cc: Julien Grall
On Fri, Sep 09, 2016 at 11:00:23AM +0100, Wei Liu wrote:
> On Thu, Sep 08, 2016 at 09:20:23AM +0200, Juergen Gross wrote:
> > Instead of passing the array size as an argument when calling
> > libxl__xs_kvs_of_flexarray() let the function get the size from the
> > array instead.
> >
> > Signed-off-
Different manuals use different representations.
A new sample looks like:
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw
000306c3)
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/cpu/common.c | 6 --
1 file changed, 4 insertions(+), 2 deletion
> I am using xen-access to write protect a lot of gfns of the machine, and
> listen to each gfn which is going to be written. For each gfn that is
> accessed for write operation I create a thread to copy its content after
> a short period of time.
> I have got the following event as I create a thre
According to Linux Kernel, Documentation/arm64/booting.txt
"
When image_size is zero, a bootloader should attempt to keep as much
memory as possible free for use by the kernel immediately after the
end of the kernel image. The amount of space required will vary
depending on selected features, and i
Also remove opencoding of PV_XSAVE_SIZE(). Undefine both when they are
done with.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/domctl.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/domctl.c b
Older guests will not use xsave even if it is available. As such, their
xcr0_accum will be 0 at the point of migrate.
If it is empty, forgo the memory allocation and serialisation into a
zero-length buffer.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
---
xen/arch/x86/domctl.c | 13 ++
Patch 5 is the primary bugfix of this series, which is broken in Xen 4.7 as
well as master. There are multiple latent security issues which would be
exposed at the point support for the first compressed xsave state was added,
but are in currently-dead code.
Andrew Cooper (6):
x86/domctl: Introd
A toolstack must call XEN_DOMCTL_getvcpuextstate twice; first to find the size
of the buffer to use, and a second time to get the actual content.
The reported size was based on v->arch.xcr0_accum, but a guest which extends
its xcr0_accum between the two hypercalls will cause the toolstack to fail
compress_xsave_states() mustn't read xstate_bv or xcomp_bv before first
confirming that the input buffer is large enough. It also doesn't cope with
compressed input. Make all of these problems the callers responsbility to
ensure.
The logic cant cope with an xstate change which would force the us
Without checking the size input, the memcpy() for the uncompressed path might
read off the end of the vcpu's xsave_area. Both callers pass the approprite
size, so hold them to it with a BUG_ON().
The compressed path is currently dead code, but its attempt to avoid leaking
uninitalised data was in
c/s da62246e "x86/xsaves: enable xsaves/xrstors/xsavec in xen" broke migration
of PV guests which were not using xsave.
In such a case, compress_xsave_states() gets passed a zero length buffer. The
first thing it tries to do is ASSERT() on user-provided data, if it hadn't
already wandered off the
>>> On 12.09.16 at 11:30, wrote:
> Different manuals use different representations.
>
> A new sample looks like:
>
> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw
> 000306c3)
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
provided ...
> --- a/xen/arch/x
On 12/09/16 10:58, Jan Beulich wrote:
On 12.09.16 at 11:30, wrote:
>> Different manuals use different representations.
>>
>> A new sample looks like:
>>
>> (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw
>> 000306c3)
>>
>> Signed-off-by: Andrew Cooper
> Acked-by: J
From: Colin Ian King
The message is missing a \n, add it.
Signed-off-by: Colin Ian King
---
arch/x86/xen/platform-pci-unplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/xen/platform-pci-unplug.c
b/arch/x86/xen/platform-pci-unplug.c
index d37a0c7..90d1b83 100
flight 100889 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100889/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 100862
Tests which
On 09/12/2016 08:26 AM, Jan Beulich wrote:
On 09.09.16 at 18:32, wrote:
>> Would that sound reasonable - am I overlooking something? To some extent this
>> might also applicable to the general case, although platform timer is now
>> only
>> used for initial seeding so probably a non-visible
On 08/09/16 17:45, Lai, Paul C wrote:
> [Paul2] in-line
If you're going to engage in discussions on xen-devel it would really be
worth your time to find a mail setup that allows you to actually quote
properly such that you can reply in-line without these manual mark-ups.
If you can't configure yo
This run is configured for baseline tests only.
flight 67697 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67697/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e9fec7326ad2f27fe368c830da055d1044b18e95
baseline v
>>> On 12.09.16 at 11:51, wrote:
> Also remove opencoding of PV_XSAVE_SIZE(). Undefine both when they are
> done with.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.
>>> On 12.09.16 at 11:51, wrote:
> A toolstack must call XEN_DOMCTL_getvcpuextstate twice; first to find the size
> of the buffer to use, and a second time to get the actual content.
>
> The reported size was based on v->arch.xcr0_accum, but a guest which extends
> its xcr0_accum between the two
>>> On 12.09.16 at 11:51, wrote:
> Older guests will not use xsave even if it is available. As such, their
> xcr0_accum will be 0 at the point of migrate.
>
> If it is empty, forgo the memory allocation and serialisation into a
> zero-length buffer.
>
> Signed-off-by: Andrew Cooper
Reviewed-b
On 12/09/16 12:20, Colin King wrote:
> From: Colin Ian King
>
> The message is missing a \n, add it.
>
> Signed-off-by: Colin Ian King
Reviewed-by: Juergen Gross
> ---
> arch/x86/xen/platform-pci-unplug.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/xen
>>> On 12.09.16 at 11:51, wrote:
> @@ -176,6 +187,11 @@ void expand_xsave_states(struct vcpu *v, void *dest,
> unsigned int size)
> u64 xstate_bv = xsave->xsave_hdr.xstate_bv;
> u64 valid;
>
> +/* Check there is state to serialise (i.e. at least an XSAVE_HDR) */
> +BUG_ON(!v->
David Vrabel writes:
> On 22/08/16 16:42, Vitaly Kuznetsov wrote:
>> Small packet loss is reported on complex multi host network configurations
>> including tunnels, NAT, ... My investigation led me to the following check
>> in netback which drops packets:
>>
>> if (unlikely(txreq.size <
On 12/09/16 12:17, Jan Beulich wrote:
On 12.09.16 at 11:51, wrote:
>> A toolstack must call XEN_DOMCTL_getvcpuextstate twice; first to find the
>> size
>> of the buffer to use, and a second time to get the actual content.
>>
>> The reported size was based on v->arch.xcr0_accum, but a guest w
Hi Sergej,
On 16/08/16 23:17, Sergej Proskurin wrote:
The HVMOP_altp2m_set_mem_access allows to set gfn permissions of
(currently one page at a time) of a specific altp2m view. In case the
view does not hold the requested gfn entry, it will be first copied from
the host's p2m table and then modi
>>> On 12.09.16 at 11:51, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -1158,7 +1158,15 @@ long arch_do_domctl(
> goto vcpuextstate_out;
> }
>
> -if ( evc->size <= PV_XSAVE_SIZE(_xcr0_accum) )
> +if ( evc->size == P
flight 67696 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67696/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-i386-sid-netboot-pvgrub 9 debian-di-install fail like 67637
test-amd64-i386-amd
On 12/09/16 12:41, Jan Beulich wrote:
On 12.09.16 at 11:51, wrote:
>> @@ -176,6 +187,11 @@ void expand_xsave_states(struct vcpu *v, void *dest,
>> unsigned int size)
>> u64 xstate_bv = xsave->xsave_hdr.xstate_bv;
>> u64 valid;
>>
>> +/* Check there is state to serialise (i.e.
On Sat, Sep 10, 2016 at 03:51:33PM +0530, Aashaka Shah wrote:
> Hello! I am Aashaka. I like computer architecture and have a good knowledge
> of C. While browsing Outreachy projects, I came across the project about
> adding PVH support to OVMF binaries. Since it looked interesting, I started
> read
>>> On 12.09.16 at 14:02, wrote:
> On 12/09/16 12:17, Jan Beulich wrote:
> On 12.09.16 at 11:51, wrote:
>>> A toolstack must call XEN_DOMCTL_getvcpuextstate twice; first to find the
> size
>>> of the buffer to use, and a second time to get the actual content.
>>>
>>> The reported size was ba
flight 100890 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100890/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5654835bd1381dfad9483b767e55db7caaeec907
baseline version:
ovmf e9fec7326ad2f27fe368c
flight 100891 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100891/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
>>> On 12.09.16 at 14:29, wrote:
> On 12/09/16 12:41, Jan Beulich wrote:
> On 12.09.16 at 11:51, wrote:
>>> @@ -205,11 +222,9 @@ void expand_xsave_states(struct vcpu *v, void *dest,
>>> unsigned int size)
>>>
>>> if ( src )
>>> {
>>> -ASSERT((xstate_offsets[in
>>> On 12.09.16 at 14:29, wrote:
> On 12/09/16 12:41, Jan Beulich wrote:
> On 12.09.16 at 11:51, wrote:
>>> @@ -205,11 +222,9 @@ void expand_xsave_states(struct vcpu *v, void *dest,
>>> unsigned int size)
>>>
>>> if ( src )
>>> {
>>> -ASSERT((xstate_offsets[in
On 12/09/16 13:14, Jan Beulich wrote:
On 12.09.16 at 11:51, wrote:
>> --- a/xen/arch/x86/domctl.c
>> +++ b/xen/arch/x86/domctl.c
>> @@ -1158,7 +1158,15 @@ long arch_do_domctl(
>> goto vcpuextstate_out;
>> }
>>
>> -if ( evc->size <= PV_XSAVE_SIZE(_xc
>>> On 12.09.16 at 11:51, wrote:
> void compress_xsave_states(struct vcpu *v, const void *src, unsigned int
> size)
> {
> struct xsave_struct *xsave = v->arch.xsave_area;
> uint16_t comp_offsets[sizeof(xfeature_mask)*8];
> -u64 xstate_bv = ((const struct xsave_struct *)src)->xsave
On 12/09/16 13:27, Jan Beulich wrote:
On 12.09.16 at 11:51, wrote:
>> void compress_xsave_states(struct vcpu *v, const void *src, unsigned int
>> size)
>> {
>> struct xsave_struct *xsave = v->arch.xsave_area;
>> uint16_t comp_offsets[sizeof(xfeature_mask)*8];
>> -u64 xstate_b
On 12/09/16 13:33, Jan Beulich wrote:
On 12.09.16 at 14:02, wrote:
>> On 12/09/16 12:17, Jan Beulich wrote:
>> On 12.09.16 at 11:51, wrote:
A toolstack must call XEN_DOMCTL_getvcpuextstate twice; first to find the
>> size
of the buffer to use, and a second time to get the actu
>>> On 12.09.16 at 15:09, wrote:
> On 12/09/16 13:33, Jan Beulich wrote:
> On 12.09.16 at 14:02, wrote:
>>> On 12/09/16 12:17, Jan Beulich wrote:
>>> On 12.09.16 at 11:51, wrote:
> A toolstack must call XEN_DOMCTL_getvcpuextstate twice; first to find the
>>> size
> of the buffer
>>> On 12.09.16 at 11:51, wrote:
> A toolstack must call XEN_DOMCTL_getvcpuextstate twice; first to find the size
> of the buffer to use, and a second time to get the actual content.
>
> The reported size was based on v->arch.xcr0_accum, but a guest which extends
> its xcr0_accum between the two
>>> On 12.09.16 at 14:46, wrote:
> On 12/09/16 13:14, Jan Beulich wrote:
> On 12.09.16 at 11:51, wrote:
>>> --- a/xen/arch/x86/domctl.c
>>> +++ b/xen/arch/x86/domctl.c
>>> @@ -1158,7 +1158,15 @@ long arch_do_domctl(
>>> goto vcpuextstate_out;
>>> }
>>>
>>> -
On 09/09/16 16:16, Jennifer Herbert wrote:
> The following code illustrates this idea:
>
> typedef struct dm_op_buffer {
> XEN_GUEST_HANDLE(void) h;
> size_t len;
> } dm_op_buffer_t;
>
> int
> HYPERVISOR_device_model_op(
> domid_t domid,
> unsigned int nr_buffers,
> XEN_GUEST_
>>> On 12.09.16 at 14:59, wrote:
> On 12/09/16 13:27, Jan Beulich wrote:
> On 12.09.16 at 11:51, wrote:
>>> void compress_xsave_states(struct vcpu *v, const void *src, unsigned int
>>> size)
>>> {
>>> struct xsave_struct *xsave = v->arch.xsave_area;
>>> uint16_t comp_offsets[size
Hi Sergej,
On 16/08/16 23:17, Sergej Proskurin wrote:
This commit moves code in the functions
"do_trap_data_(instr|abort)_guest" without changing the original
functionality. The code movement is limited to moving the struct npfec
out of the switch statements in both functions. This commit acts a
On 12/09/16 13:43, Jan Beulich wrote:
On 12.09.16 at 14:29, wrote:
>> On 12/09/16 12:41, Jan Beulich wrote:
>> On 12.09.16 at 11:51, wrote:
@@ -205,11 +222,9 @@ void expand_xsave_states(struct vcpu *v, void *dest,
unsigned int size)
if ( src )
>>> On 12.09.16 at 15:57, wrote:
> On 12/09/16 13:43, Jan Beulich wrote:
> On 12.09.16 at 14:29, wrote:
>>> On 12/09/16 12:41, Jan Beulich wrote:
>>> On 12.09.16 at 11:51, wrote:
> @@ -205,11 +222,9 @@ void expand_xsave_states(struct vcpu *v, void *dest,
> unsigned int size)
>
On 09/09/16 16:41, Tamas K Lengyel wrote:
> When emulating instructions the emulator maintains a small i-cache fetched
> from the guest memory. Under certain scenarios this memory region may contain
> instructions that a monitor subscriber would prefer to hide, namely INT3, and
> instead would pref
Hello Sergej,
On 16/08/16 23:17, Sergej Proskurin wrote:
This commit adds the function "altp2m_lazy_copy" implementing the altp2m
paging mechanism. The function "altp2m_lazy_copy" lazily copies the
hostp2m's mapping into the currently active altp2m view on 2nd stage
translation faults on instruc
Hello Sergej,
On 16/08/16 23:17, Sergej Proskurin wrote:
This commit adds the functionality to change mfn mappings for specified
gfn's in altp2m views. This mechanism can be used within the context of
VMI, e.g., to establish stealthy debugging.
Signed-off-by: Sergej Proskurin
---
Cc: Stefano S
Hello Sergej,
On 16/08/16 23:17, Sergej Proskurin wrote:
Signed-off-by: Sergej Proskurin
---
Cc: Stefano Stabellini
Cc: Julien Grall
---
v2: Dump p2m information of the hostp2m and all altp2m views.
---
xen/arch/arm/p2m.c | 20
1 file changed, 20 insertions(+)
diff --gi
On Sep 12, 2016 08:17, "George Dunlap" wrote:
>
> On 09/09/16 16:41, Tamas K Lengyel wrote:
> > When emulating instructions the emulator maintains a small i-cache
fetched
> > from the guest memory. Under certain scenarios this memory region may
contain
> > instructions that a monitor subscriber wo
>>> On 09.09.16 at 17:16, wrote:
> The following code illustrates this idea:
>
> typedef struct dm_op_buffer {
> XEN_GUEST_HANDLE(void) h;
> size_t len;
> } dm_op_buffer_t;
This implies that we'll lose all type safety on the handles passed, as
is also emphasized by the use of raw_copy_
On 12/09/16 15:31, Tamas Lengyel wrote:
> On Sep 12, 2016 08:17, "George Dunlap" wrote:
>>
>> On 09/09/16 16:41, Tamas K Lengyel wrote:
>>> When emulating instructions the emulator maintains a small i-cache
> fetched
>>> from the guest memory. Under certain scenarios this memory region may
> conta
Hi Shannon,
On 02/09/16 03:55, Shannon Zhao wrote:
From: Shannon Zhao
It only constructs the ACPI tables for 64-bit ARM DomU when user enables
acpi because 32-bit DomU doesn't support ACPI. And the generation codes
are only built for 64-bit toolstack.
Signed-off-by: Shannon Zhao
Acked-by:
Hi Shannon,
On 02/09/16 03:55, Shannon Zhao wrote:
From: Shannon Zhao
It uses static DSDT table like the way x86 uses. Currently the DSDT
table only contains processor device objects and it generates the
maximal objects which so far is 128.
While the GUEST_MAX_VCPUS is defined under __XEN__ o
>>> On 09.09.16 at 17:41, wrote:
> When emulating instructions the emulator maintains a small i-cache fetched
> from the guest memory. Under certain scenarios this memory region may contain
> instructions that a monitor subscriber would prefer to hide, namely INT3, and
> instead would prefer to em
Hi Shannon,
On 02/09/16 03:55, Shannon Zhao wrote:
From: Shannon Zhao
Construct ACPI RSDP table and add a helper to calculate the ACPI table
checksum.
Signed-off-by: Shannon Zhao
Acked-by: Julien Grall
Regards,
---
tools/libxl/libxl_arm_acpi.c | 39
On 12/09/16 15:56, Jan Beulich wrote:
On 09.09.16 at 17:41, wrote:
>> When emulating instructions the emulator maintains a small i-cache fetched
>> from the guest memory. Under certain scenarios this memory region may contain
>> instructions that a monitor subscriber would prefer to hide, nam
On Thu, Aug 18, 2016 at 12:42 AM, Dario Faggioli
wrote:
> On Wed, 2016-08-17 at 19:17 +0200, Dario Faggioli wrote:
>> If there are idle pcpus inside the waking vcpu's
>> soft-affinity mask, we should really tickle one
>> of them (this is one of the purposes of the
>> __runq_tickle() function itsel
On Sep 12, 2016 08:59, "George Dunlap" wrote:
>
> On 12/09/16 15:56, Jan Beulich wrote:
> On 09.09.16 at 17:41, wrote:
> >> When emulating instructions the emulator maintains a small i-cache
fetched
> >> from the guest memory. Under certain scenarios this memory region may
contain
> >> instr
Hi Shannon,
On 02/09/16 03:55, Shannon Zhao wrote:
From: Shannon Zhao
Signed-off-by: Shannon Zhao
Acked-by: Julien Grall
Regards,
---
tools/libxl/libxl_arm_acpi.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/li
On 17/08/16 18:17, Dario Faggioli wrote:
> If, when vcpu x wakes up, there are no idle pcpus in x's
> soft-affinity, we just go ahead and look at its hard
> affinity. This basically means that, if, in __runq_tickle(),
> new_idlers_empty is true, balance_step is equal to
> CSCHED_BALANCE_HARD_AFFINI
Hi Shannon,
On 02/09/16 03:55, Shannon Zhao wrote:
From: Shannon Zhao
Construct GTDT table with the interrupt information of timers.
Signed-off-by: Shannon Zhao
---
tools/libxl/libxl_arm_acpi.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/tools
Hi Shannon,
On 02/09/16 03:55, Shannon Zhao wrote:
From: Shannon Zhao
According to the GIC version, construct the MADT table.
Signed-off-by: Shannon Zhao
Acked-by: Julien Grall
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lis
Hi Shannon,
On 02/09/16 03:55, Shannon Zhao wrote:
From: Shannon Zhao
Signed-off-by: Shannon Zhao
Acked-by: Julien Grall
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Hi Shannon,
On 02/09/16 03:55, Shannon Zhao wrote:
From: Shannon Zhao
Copy the static DSDT table into ACPI blob.
Signed-off-by: Shannon Zhao
Acked-by: Julien Grall
Regards,
---
tools/libxl/libxl_arm_acpi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/libxl/lib
On 17/08/16 18:17, Dario Faggioli wrote:
> If vcpu x has run for 200us, and sched_ratelimit_us is
> 1000us, continue running x _but_ return 1000us-200us as
> the next time slice. This way, next scheduling point will
> happen in 800us, i.e., exactly at the point when x crosses
> the threshold, and c
1 - 100 of 158 matches
Mail list logo
