flight 101230 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101230/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 16 guest-start.2fail REGR. vs. 101216
Regressions which
This run is configured for baseline tests only.
flight 67785 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67785/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 6 xen-boot
This run is configured for baseline tests only.
flight 67786 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67786/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ed72804638c9b240477c5235d72c3823483813b2
baseline v
flight 101228 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101228/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101225
test-amd64-i386-xl-qemuu-wi
On Thu, Sep 29, 2016 at 10:54 PM, Dario Faggioli
wrote:
> As far as {csched, csched2, rt}_schedule() are concerned,
> an "empty" event, would already make it easier to read and
> understand a trace.
>
> But while there, add a few useful information, like
> if the cpu that is going through the sche
On Fri, Sep 30, 2016 at 10:21 AM, Dario Faggioli
wrote:
> As far as {csched, csched2, rt}_schedule() are concerned,
> an "empty" event, would already make it easier to read and
> understand a trace.
>
> But while there, add a few useful information, like
> if the cpu that is going through the sche
flight 101229 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101229/
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 Thu, Aug 25, 2016 at 01:22:45PM +0800, Yi Sun wrote:
> This patch is the xl/xc changes to support Intel L2 CAT
> (Cache Allocation Technology).
>
> The new level option is introduced to original CAT setting
> command in order to set CBM for specified level CAT.
> - 'xl psr-hwinfo' is updated to
On Thu, Sep 22, 2016 at 10:15:44AM +0800, Yi Sun wrote:
> Add L2 CAT (Cache Allocation Technology) feature support in
> hypervisor:
> - Implement 'struct feat_ops' callback functions for L2 CAT
> and initialize L2 CAT feature and add it into feature list.
> - Add new sysctl to get L2 CAT informat
On Thu, Sep 22, 2016 at 10:15:20AM +0800, Yi Sun wrote:
> Current psr.c is designed for supporting L3 CAT/CDP. It has many
> limitations to add new feature. Considering to support more PSR
> features, we need refactor PSR implementation to make it more
> flexible and fulfill the principle, open for
On Thu, Sep 22, 2016 at 10:14:00AM +0800, Yi Sun wrote:
> Design document is below:
Could the design document be a patch itself please?
Meaning it will be added in docs/misc/ ?
Also is there a git tree for your patches?
Thanks.
___
Xen-devel mailing
On 9/30/2016 3:47 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 30, 2016 at 03:20:09PM -0400, Jason Dickens wrote:
Thanks Konrad,
[CC-ing Xen-devel again.]
I think you and David have successfully answered my question and pointed me
to the key code. I have already verified that the device operat
On Fri, Sep 30, 2016 at 03:20:09PM -0400, Jason Dickens wrote:
> Thanks Konrad,
[CC-ing Xen-devel again.]
>
> I think you and David have successfully answered my question and pointed me
> to the key code. I have already verified that the device operates if I move
> it into the space of the TPM, b
On Fri, Sep 30, 2016 at 07:51:05PM +0100, Andrew Cooper wrote:
> On 30/09/16 19:11, Konrad Rzeszutek Wilk wrote:
> > diff --git a/xen/common/tmem_control.c b/xen/common/tmem_control.c
> > index fc20a9f..151d8ef 100644
> > --- a/xen/common/tmem_control.c
> > +++ b/xen/common/tmem_control.c
> > @@ -2
On 30/09/16 19:11, Konrad Rzeszutek Wilk wrote:
> These operations are used during the save process of migration.
> Instead of doing 64 hypercalls lets do just one. We modify
> the 'struct xen_tmem_client' structure (used in
> XEN_SYSCTL_TMEM_OP_[GET|SET]_CLIENT_INFO) to have an extra field
> 'nr_p
flight 101225 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101225/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 9 debian-install fail like 101215
test-amd64-i386-xl-qemut-wi
On 30/09/16 19:11, Konrad Rzeszutek Wilk wrote:
> That is what they are used for. Lets make it more clear.
>
> Of all the various sub-commands, the only one that needed
> semantic change is XEN_SYSCTL_TMEM_OP_SAVE_BEGIN. That in the
> past used 'arg1', and now we are moving it to use 'arg'.
> Since
On 30/09/16 19:11, Konrad Rzeszutek Wilk wrote:
> return values. For success they used to be 1 ([SAVE,RESTORE]_BEGIN),
> 0 if guest did not have any tmem (but only for SAVE_BEGIN), and
> -1 for any type of failure.
>
> And SAVE_END (which you would think would mirror SAVE_BEGIN)
> had 0 for success
On 30/09/16 19:11, Konrad Rzeszutek Wilk wrote:
> diff --git a/xen/common/tmem_control.c b/xen/common/tmem_control.c
> index fc20a9f..151d8ef 100644
> --- a/xen/common/tmem_control.c
> +++ b/xen/common/tmem_control.c
> @@ -258,43 +258,56 @@ static int tmemc_list(domid_t cli_id,
> tmem_cli_va_param
On Fri, Sep 30, 2016 at 10:29:20AM -0400, Jason Dickens wrote:
> Thanks David,
>
> This could very well be the issue, but could you please elaborate?
> The questions that come up are the following:
> What is the physical address range given to RAM? What range of addresses
> would work for my devic
flight 101227 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101227/
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 30/09/16 19:11, Konrad Rzeszutek Wilk wrote:
> in its own structure. This paves the way to make only
> one hypercall to retrieve/set this information instead of multiple
> ones.
>
> Acked-by: Wei Liu
> Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: Andrew Cooper
On 30/09/16 19:11, Konrad Rzeszutek Wilk wrote:
> No functional change. We do this to prepare for another
> entry to be added in the union. See patch titled:
> "tmem/libxc: Squash XEN_SYSCTL_TMEM_OP_[SET|SAVE]"
>
> Signed-off-by: Konrad Rzeszutek Wilk
Acked-by: Andrew Cooper
___
On 30/09/16 19:11, Konrad Rzeszutek Wilk wrote:
> Couple of reasons:
> - It can lead to security issues (see row-hammer, KSM and such
>attacks).
> - Code is quite complex.
> - Deduplication is good if the pages themselves are the same
>but that is hardly guaranteed.
> - We got some gain
On Fri, Sep 30, 2016 at 02:11:51PM -0400, Konrad Rzeszutek Wilk wrote:
> ---
> tools/libxc/xc_tmem.c | 73 +++
> tools/libxl/libxl.c | 26 +++---
> tools/python/xen/lowlevel/xc/xc.c | 2 -
Acked-by: Wei Liu
> xen/common/tmem.c
The only thing this hypercall returns is TMEM_SPEC_VERSION.
The comment around is also misleading - this call does not
do any domain operation.
Acked-by: Wei Liu
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Ian Jackson
Cc: Wei Liu
v1: Initial submission.
v2: Added Wei's Ack.
---
tools/libx
in its own structure. This paves the way to make only
one hypercall to retrieve/set this information instead of multiple
ones.
Acked-by: Wei Liu
Signed-off-by: Konrad Rzeszutek Wilk
---
v1: First submission.
v2: Rebase on " tmem: Retire XEN_SYSCTL_TMEM_OP_[SET_CAP|SAVE_GET_CLIENT_CAP]"
which
It is not used by anything. Its intent was to complement
the 'weight' attribute but there hadn't been any request for this.
If there is a need to resurface it, it can be integrated back
via the XEN_SYSCTL_TMEM_SET_CLIENT_INFO introduced in
"tmem/libxc: Squash XEN_SYSCTL_TMEM_OP_[SET|SAVE].."
Acke
Couple of reasons:
- It can lead to security issues (see row-hammer, KSM and such
attacks).
- Code is quite complex.
- Deduplication is good if the pages themselves are the same
but that is hardly guaranteed.
- We got some gains (if pages are deduped) but at the cost of
making code les
Specifically:
XEN_SYSCTL_TMEM_OP_SET_[WEIGHT,COMPRESS] are now done via:
XEN_SYSCTL_TMEM_SET_CLIENT_INFO
and XEN_SYSCTL_TMEM_OP_SAVE_GET_[VERSION,MAXPOOLS,
CLIENT_WEIGHT, CLIENT_FLAGS] can now be retrieved via:
XEN_SYSCTL_TMEM_GET_CLIENT_INFO
All this information is now in 'struct xen_tmem_c
return values. For success they used to be 1 ([SAVE,RESTORE]_BEGIN),
0 if guest did not have any tmem (but only for SAVE_BEGIN), and
-1 for any type of failure.
And SAVE_END (which you would think would mirror SAVE_BEGIN)
had 0 for success and -1 if guest did not any tmem enabled for it.
This is
These operations are used during the save process of migration.
Instead of doing 64 hypercalls lets do just one. We modify
the 'struct xen_tmem_client' structure (used in
XEN_SYSCTL_TMEM_OP_[GET|SET]_CLIENT_INFO) to have an extra field
'nr_pools'. Armed with that the code slurping up pages from the
That is what they are used for. Lets make it more clear.
Of all the various sub-commands, the only one that needed
semantic change is XEN_SYSCTL_TMEM_OP_SAVE_BEGIN. That in the
past used 'arg1', and now we are moving it to use 'arg'.
Since that code is only used during migration which is tied
to t
No functional change. We do this to prepare for another
entry to be added in the union. See patch titled:
"tmem/libxc: Squash XEN_SYSCTL_TMEM_OP_[SET|SAVE]"
Signed-off-by: Konrad Rzeszutek Wilk
---
v2: New submission.
---
tools/libxc/xc_tmem.c | 4 ++--
xen/common/tmem.c | 8
Hey!
Since v1: [https://lists.xen.org/archives/html/xen-devel/2016-09/msg03035.html]
- Squashes some patches
- Added Wei's Acked-by
- Reworked some patches.
This batch of fixes slowly marches toward ripping out pieces
of code in tmem that are hard to maintain and improve on code
that was orgin
On Fri, Sep 30, 2016 at 10:19:06AM +0800, Lan Tianyu wrote:
> Dumping timer info may run for a long time on the huge machine with
> a lot of physical cpus. To avoid triggering NMI watchdog, add
> process_pending_softirqs() in the loop of dumping timer info.
Reviewed-by: Konrad Rzeszutek Wilk
>
On Wed, Sep 28, 2016 at 01:47:56AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 19:43, wrote:
> > Finally found the vmfunc opcode page in Vol 3 30.3, VMX Instruction
> > Reference.
> > Agreed, there's no mention of prefixes, "pfx", on this page. It appears
> > that the other VMX instructions i
On Fri, Sep 30, 2016 at 10:19:05AM +0800, Lan Tianyu wrote:
> Keyhandler may run for a long time in a timer handler on the large machine
I am bit lost.
You say 'timer handler' which will imply that there is some form
of 'init_timer' and 'set_timer' that would call the handle_keypress
function?
Bu
On 27/09/16 16:57, Roger Pau Monne wrote:
> Signed-off-by: Roger Pau Monné
Acked-by: George Dunlap
With one note: You might consider changing the summary to "Allow HVM
hardware domains (PVHv2 dom0) to perform..."
That makes it clear to someone casually scanning that you're really
enabling all
On 27/09/16 16:57, Roger Pau Monne wrote:
> ... and remove hap_set_alloc_for_pvh_dom0.
>
> Signed-off-by: Roger Pau Monné
> Acked-by: Tim Deegan
Acked-by: George Dunlap
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Tim Deegan
> ---
> Changes since RFC:
> - Make pa
On 30/09/16 17:56, George Dunlap wrote:
> On 27/09/16 16:56, Roger Pau Monne wrote:
>> ... and using the "preempted" parameter. The solution relies on just calling
>> softirq_pending if the current domain is the idle domain.
>>
>> Signed-off-by: Roger Pau Monné
>
> You probably also want to add s
On 27/09/16 16:56, Roger Pau Monne wrote:
> ... and using the "preempted" parameter. The solution relies on just calling
> softirq_pending if the current domain is the idle domain.
>
> Signed-off-by: Roger Pau Monné
You probably also want to add something to the effect of:
"This allows us to ca
On Fri, Sep 30, 2016 at 08:56:03AM -0600, Jan Beulich wrote:
> >>> On 30.09.16 at 16:36, wrote:
> > On Wed, Sep 28, 2016 at 06:56:40AM -0600, Jan Beulich wrote:
> >> >>> On 28.09.16 at 11:42, wrote:
> >> > Note: We still have to do this awkward 'guest_handle_cast'
> >> > otherwise it will not com
On 27/09/16 16:56, Roger Pau Monne wrote:
> Return should be an int, and the number of pages should be an unsigned long.
>
> Signed-off-by: Roger Pau Monné
Non-shadow mm bits:
Acked-by: George Dunlap
> ---
> Cc: George Dunlap
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Tim Deegan
> ---
>
flight 101226 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101226/
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 30/09/16 17:04, Igor Druzhinin wrote:
> On 30/09/16 15:46, George Dunlap wrote:
>> On 29/09/16 14:53, Igor Druzhinin wrote:
>>> As long as t_info_first_offset is calculated in uint32_t offsets we
>>> need to
>>> multiply it by sizeof(uint32_t) in order to get the right number of
>>> pages
>>> fo
On 30/09/16 15:46, George Dunlap wrote:
On 29/09/16 14:53, Igor Druzhinin wrote:
As long as t_info_first_offset is calculated in uint32_t offsets we need to
multiply it by sizeof(uint32_t) in order to get the right number of pages
for trace metadata. Not doing that makes it impossible to read th
Dario Faggioli writes ("Re: [Xen-devel] [PATCH v2 10/10] xl: allow to set the
ratelimit value online for Credit2"):
> I mean, AFAICT, there's xl calling a libxl function and printing an
> error if it fails. The libxl function also logs an error --true-- but
> this seems rather common to me, and ap
On Fri, 2016-09-30 at 11:34 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH v2 10/10] xl: allow to set
> theratelimit value online for Credit2"):
> >
> > +static int sched_credit2_params_set(int poolid,
> > +libxl_sched_credit2_params
> > *scinfo)
>
>
>>> On 27.09.16 at 17:57, wrote:
> @@ -43,6 +44,11 @@ static long __initdata dom0_nrpages;
> static long __initdata dom0_min_nrpages;
> static long __initdata dom0_max_nrpages = LONG_MAX;
>
> +/* Size of the VM86 TSS for virtual 8086 mode to use. */
> +#define HVM_VM86_TSS_SIZE 128
> +
> +st
On 30/09/16 16:47, Wei Liu wrote:
> Clang complains:
>
> emulate.c:65:3: error: duplicate 'const' declaration specifier
> [-Werror,-Wduplicate-decl-specifier]
> } const opc_tab[INSTR_MAX_COUNT] = {
> ^
>
> Remove that const to fix the issue.
>
> Signed-off-by: Wei Liu
Reviewed-by: Andrew
Clang complains:
emulate.c:65:3: error: duplicate 'const' declaration specifier
[-Werror,-Wduplicate-decl-specifier]
} const opc_tab[INSTR_MAX_COUNT] = {
^
Remove that const to fix the issue.
Signed-off-by: Wei Liu
---
xen/arch/x86/hvm/svm/emulate.c | 2 +-
1 file changed, 1 insertion(
On Thu, Sep 29, 2016 at 08:26:04AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57, wrote:
> > +static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
> > +{
> > +
> > +if ( is_hvm_domain(d) )
> > +{
> > +if ( is_hardware_domain(d) &&
> > + emflag
On 17/08/16 18:20, Dario Faggioli wrote:
> Credit2 is already event based, rather than tick
> based. This means, the time at which the (i+1)-eth
> scheduling decision needs to happen is computed
> during the i-eth scheduling decision, and a timer
> is set accordingly.
>
> If there's nothing immine
On 30/09/16 15:21, Dario Faggioli wrote:
> And here they are, the last two remaining patches...
>
> Dario
> ---
> Dario Faggioli (2):
> xen: credit2: implement yield()
> xen: tracing: add trace records for schedule and rate-limiting.
Applied, thanks.
-George
>
> xen/common/sched_
>>> On 27.09.16 at 17:57, wrote:
> ... and introduce a floor variant.
I dislike this, not the least because of the many places you touch
just to tack that odd suffix on. Unless you plan on adding half a
dozen or more callers to that floor variant, I think it would be
prudent to not introduce such
On 30/09/16 15:21, Dario Faggioli wrote:
> When a vcpu explicitly yields it is usually giving
> us an advice of "let someone else run and come back
> to me in a bit."
>
> Credit2 isn't, so far, doing anything when a vcpu
> yields, which means an yield is basically a NOP (well,
> actually, it's pur
>>> On 30.09.16 at 17:02, wrote:
> On Fri, Sep 30, 2016 at 07:21:41AM -0600, Jan Beulich wrote:
>> >>> On 30.09.16 at 13:27, wrote:
>> > On Thu, Sep 29, 2016 at 08:18:36AM -0600, Jan Beulich wrote:
>> >> >>> On 27.09.16 at 17:57, wrote:
>> >> > +{
>> >> > +int rc;
>> >> > +
>> >> > +whil
>>> On 27.09.16 at 17:57, wrote:
> So that it can be called from the Dom0 builder.
Why would the Dom0 builder need to call it, when it doesn't so far?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 27.09.16 at 17:57, wrote:
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -663,6 +663,13 @@ Pin dom0 vcpus to their respective pcpus
>
> Flag that makes a 64bit dom0 boot in PVH mode. No 32bit support at present.
>
> +### dom0hvm
> +> `= `
>
On Fri, Sep 30, 2016 at 07:21:41AM -0600, Jan Beulich wrote:
> >>> On 30.09.16 at 13:27, wrote:
> > On Thu, Sep 29, 2016 at 08:18:36AM -0600, Jan Beulich wrote:
> >> >>> On 27.09.16 at 17:57, wrote:
> >> > +{
> >> > +int rc;
> >> > +
> >> > +while ( nr_pages > 0 )
> >> > +{
> >> > +
On 09/30/2016 10:56 AM, Jan Beulich wrote:
On 30.09.16 at 16:54, wrote:
>> On 09/30/2016 10:44 AM, Jan Beulich wrote:
> +int
> +x86_insn_modrm(const struct x86_emulate_state *state,
> + unsigned int *rm, unsigned int *reg)
> +{
> +check_state(state);
>>> On 30.09.16 at 16:54, wrote:
> On 09/30/2016 10:44 AM, Jan Beulich wrote:
>>
+int
+x86_insn_modrm(const struct x86_emulate_state *state,
+ unsigned int *rm, unsigned int *reg)
+{
+check_state(state);
+
+if ( !(state->desc & ModRM) )
On Thu, Sep 29, 2016 at 11:48:43AM +0100, Wei Liu wrote:
> On Thu, Sep 29, 2016 at 03:36:00AM -0600, Jan Beulich wrote:
> > >>> On 29.09.16 at 11:23, wrote:
> > > On Thu, Sep 29, 2016 at 01:03:02AM -0600, Jan Beulich wrote:
> > >> >>> On 29.09.16 at 01:48, wrote:
> > >> > @@ -265,11 +266,30 @@ vo
>>> On 30.09.16 at 16:36, wrote:
> On Wed, Sep 28, 2016 at 06:56:40AM -0600, Jan Beulich wrote:
>> >>> On 28.09.16 at 11:42, wrote:
>> > Note: We still have to do this awkward 'guest_handle_cast'
>> > otherwise it will not compile on ARM - which defines _two_
>> > of these macros (__guest_handle_
On 09/30/2016 10:44 AM, Jan Beulich wrote:
>
>>> +int
>>> +x86_insn_modrm(const struct x86_emulate_state *state,
>>> + unsigned int *rm, unsigned int *reg)
>>> +{
>>> +check_state(state);
>>> +
>>> +if ( !(state->desc & ModRM) )
>>> +return -EINVAL;
>>> +
>>> +if (
>>> On 30.09.16 at 16:46, wrote:
> On 30/09/16 15:44, Jan Beulich wrote:
+int
+x86_insn_modrm(const struct x86_emulate_state *state,
+ unsigned int *rm, unsigned int *reg)
+{
+check_state(state);
+
+if ( !(state->desc & ModRM) )
+
On 30/09/16 15:46, George Dunlap wrote:
> On 29/09/16 14:53, Igor Druzhinin wrote:
>> As long as t_info_first_offset is calculated in uint32_t offsets we need to
>> multiply it by sizeof(uint32_t) in order to get the right number of pages
>> for trace metadata. Not doing that makes it impossible to
On 30/09/16 15:46, George Dunlap wrote:
> On 29/09/16 14:53, Igor Druzhinin wrote:
>> > As long as t_info_first_offset is calculated in uint32_t offsets we need to
>> > multiply it by sizeof(uint32_t) in order to get the right number of pages
>> > for trace metadata. Not doing that makes it impossi
On 07/09/16 18:18, Boris Ostrovsky wrote:
> New CPU hotplug framework was introduced recently. These patches convert Xen
> CPU hotplug code to this infrastructure.
Applied to for-linus-4.9, thanks.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.o
On 30/09/16 15:44, Jan Beulich wrote:
>>> +int
>>> +x86_insn_modrm(const struct x86_emulate_state *state,
>>> + unsigned int *rm, unsigned int *reg)
>>> +{
>>> +check_state(state);
>>> +
>>> +if ( !(state->desc & ModRM) )
>>> +return -EINVAL;
>>> +
>>> +if ( rm )
>
On 22/09/16 09:45, Juergen Gross wrote:
> Support the driver_override scheme introduced with commit 782a985d7af2
> ("PCI: Introduce new device binding path using pci_dev.driver_override")
Applied to for-linus-4.9, thanks.
David
___
Xen-devel mailing li
On 29/09/16 14:53, Igor Druzhinin wrote:
> As long as t_info_first_offset is calculated in uint32_t offsets we need to
> multiply it by sizeof(uint32_t) in order to get the right number of pages
> for trace metadata. Not doing that makes it impossible to read the trace
> buffer correctly from users
On 26/08/16 22:55, KarimAllah Ahmed wrote:
> Ever since commit 254d1a3f02eb ("xen/pv-on-hvm kexec: shutdown watches
> from old kernel") using the INTx interrupt from Xen PCI platform device for
> event channel notification would just lockup the guest during bootup.
> postcore_initcall now calls xs_
>>> On 30.09.16 at 16:37, wrote:
> On 09/30/2016 05:38 AM, Jan Beulich wrote:
>> +if ( opc_tab[instr].opcode == ctxt.ctxt.opcode )
>> {
>> -if ( (inst_len + i) >= fetch_len )
>> -{
>> -if ( !fetch(vmcb, buf + fetch_len, fetch_addr + fetch_l
On 09/30/2016 05:38 AM, Jan Beulich wrote:
> +if ( opc_tab[instr].opcode == ctxt.ctxt.opcode )
> {
> -if ( (inst_len + i) >= fetch_len )
> -{
> -if ( !fetch(vmcb, buf + fetch_len, fetch_addr + fetch_len,
> -max_le
On Wed, Sep 28, 2016 at 06:56:40AM -0600, Jan Beulich wrote:
> >>> On 28.09.16 at 11:42, wrote:
> > Note: We still have to do this awkward 'guest_handle_cast'
> > otherwise it will not compile on ARM - which defines _two_
> > of these macros (__guest_handle_64_xen_sysctl_tmem_client_t
> > and __gu
Thanks David,
This could very well be the issue, but could you please elaborate?
The questions that come up are the following:
What is the physical address range given to RAM? What range of addresses
would work for my device?
And, if this is the case, how would I unpopulate the RAM?
There are
As far as {csched, csched2, rt}_schedule() are concerned,
an "empty" event, would already make it easier to read and
understand a trace.
But while there, add a few useful information, like
if the cpu that is going through the scheduler has
been tickled or not, if it is currently idle, etc
(they va
And here they are, the last two remaining patches...
Dario
---
Dario Faggioli (2):
xen: credit2: implement yield()
xen: tracing: add trace records for schedule and rate-limiting.
xen/common/sched_credit.c| 32 +++
xen/common/sched_credit2.c | 92
When a vcpu explicitly yields it is usually giving
us an advice of "let someone else run and come back
to me in a bit."
Credit2 isn't, so far, doing anything when a vcpu
yields, which means an yield is basically a NOP (well,
actually, it's pure overhead, as it causes the scheduler
kick in, but the
On 30/09/16 14:36, Jan Beulich wrote:
> System gates with type 0 shouldn't have what might be their DPL altered
> - such descriptors can't be used anyway without incurring a #GP, and
> hence adjusting its DPL is only risking to confuse the guest.
>
> Also bail right away for non-present descriptors
On Fri, 2016-09-30 at 15:10 +0100, George Dunlap wrote:
> On 30/09/16 15:06, Dario Faggioli wrote:
> > Mm... looks to me that
> >
> > 3/10 xen: credit2: make tickling more deterministic
> >
> > is also missing? Or should I re-`git pull' (I've just done that,
> > though...)?
>
> I see it there i
On 30/09/16 14:17, Jan Beulich wrote:
> Minimal emulation: XBEGIN aborts right away, hence
> - XABORT is just a no-op,
> - XEND always raises #GP,
> - XTEST always signals neither RTM nor HLE are active.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Explicitly generate #UD for xtest and xend.
>
> ---
On 30/09/16 15:06, Dario Faggioli wrote:
> On Fri, 2016-09-30 at 14:51 +0100, George Dunlap wrote:
>> On 30/09/16 03:53, Dario Faggioli wrote:
>>>
>>> Dario Faggioli (10):
>> [snip]
>>>
>>> xen: credit2: implement yield()
>>> xen: tracing: add trace records for schedule and rate-
>>>
flight 101224 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/101224/
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 Fri, 2016-09-30 at 14:51 +0100, George Dunlap wrote:
> On 30/09/16 03:53, Dario Faggioli wrote:
> >
> > Dario Faggioli (10):
> [snip]
> >
> > xen: credit2: implement yield()
> > xen: tracing: add trace records for schedule and rate-
> > limiting.
>
> I've pushed everything but the
On Wed, Sep 28, 2016 at 06:10:58AM -0600, Jan Beulich wrote:
> >>> On 28.09.16 at 11:42, wrote:
> > It is not used by anything.
>
> But that shouldn't be the only aspect. Are they also not useful for
> anything?
As far as I can see it was meant to complement the 'weight'. But the
code just hangs
On Fri, 2016-09-30 at 13:52 +0100, George Dunlap wrote:
> On 30/09/16 03:53, Dario Faggioli wrote:
> >
> > When a vcpu explicitly yields it is usually giving
> > us an advice of "let someone else run and come back
> > to me in a bit."
> >
> > Credit2 isn't, so far, doing anything when a vcpu
> >
On 30/09/16 14:35, Jason Dickens wrote:
> Hi Wei,
>
> Thanks for the response. It make sense to me that if the device were on
> the PCI bus (or other such bus, e.g. USB) that it could be discovered,
> at least by an OS. Its something to consider. I should mention that our
> guest VM doesn't actual
On 30/09/16 03:53, Dario Faggioli wrote:
> Hey,
>
> This is v2 of my Credit1 and Credit2 improvements series. First posting is
> here:
>
> https://lists.xen.org/archives/html/xen-devel/2016-08/msg02183.html
>
> Now, couple of things:
> - some of the patches have been applied already out of v1;
System gates with type 0 shouldn't have what might be their DPL altered
- such descriptors can't be used anyway without incurring a #GP, and
hence adjusting its DPL is only risking to confuse the guest.
Also bail right away for non-present descriptors - no need to write
back anything in that case.
Hi Wei,
Thanks for the response. It make sense to me that if the device were on
the PCI bus (or other such bus, e.g. USB) that it could be discovered,
at least by an OS. Its something to consider. I should mention that our
guest VM doesn't actually use an OS.
However, the device is not imple
On 30/09/16 13:04, Dario Faggioli wrote:
> On Fri, 2016-09-30 at 11:24 +0100, Ian Jackson wrote:
>> Dario Faggioli writes ("[PATCH v2 08/10] libxl: fix coding style of
>> credit1 parameters related functions"):
>>> int libxl_sched_credit_params_set(libxl_ctx *ctx, uint32_t poolid,
>>>
>>> On 30.09.16 at 13:27, wrote:
> On Thu, Sep 29, 2016 at 08:18:36AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57, wrote:
>> > +{
>> > +int rc;
>> > +
>> > +while ( nr_pages > 0 )
>> > +{
>> > +rc = (map ? map_mmio_regions : unmap_mmio_regions)
>> > + (d,
On 30/09/16 14:16, Jan Beulich wrote:
> Use a single set of variables throughout the huge switch() statement,
> allowing to funnel SLDT/STR into the mov-from-sreg code path.
>
> Signed-off-by: Jan Beulich
> Reviewed-by: Andrew Cooper
Also looking better.
~Andrew
___
On 30/09/16 14:16, Jan Beulich wrote:
> To make this complete, also add support for SLDT and STR. Note that by
> just looking at the guest CR4 bit, this is independent of actually
> making available the UMIP feature to guests.
>
> Signed-off-by: Jan Beulich
Much clearer.
Reviewed-by: Andrew Coop
Considering that we surface MPX to HVM guests, instructions we emulate
should also correctly deal with MPX state. While for now BND*
instructions don't get emulated, the effect of branches (which we do
emulate) without BND prefix should be taken care of.
No need to alter XABORT behavior: While not
Minimal emulation: XBEGIN aborts right away, hence
- XABORT is just a no-op,
- XEND always raises #GP,
- XTEST always signals neither RTM nor HLE are active.
Signed-off-by: Jan Beulich
---
v2: Explicitly generate #UD for xtest and xend.
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch
On 30/09/16 03:54, Dario Faggioli wrote:
> As far as {csched, csched2, rt}_schedule() are concerned,
> an "empty" event, would already make it easier to read and
> understand a trace.
>
> But while there, add a few useful information, like
> if the cpu that is going through the scheduler has
> bee
1 - 100 of 168 matches
Mail list logo
