[Xen-devel] [qemu-mainline test] 101230: regressions - FAIL

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

[Xen-devel] [qemu-mainline baseline-only test] 67785: regressions - FAIL

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

[Xen-devel] [ovmf baseline-only test] 67786: all pass

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

[Xen-devel] [xen-unstable test] 101228: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH v2 06/10] xen: tracing: add trace records for schedule and rate-limiting.

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

Re: [Xen-devel] [PATCH v3 2/2] xen: tracing: add trace records for schedule and rate-limiting.

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

[Xen-devel] [xen-unstable-smoke test] 101229: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH 3/3] tools & docs: add L2 CAT support in tools and docs.

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

Re: [Xen-devel] [v2 2/3] x86: add support for L2 CAT in hypervisor.

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

Re: [Xen-devel] [v2 1/3] x86: refactor psr implementation in hypervisor.

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

Re: [Xen-devel] Adding new custom devices to Xen via QEMU

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

Re: [Xen-devel] Adding new custom devices to Xen via QEMU

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,

Re: [Xen-devel] [PATCH v2 6/9] tmem/libxc: Squash XEN_SYSCTL_TMEM_OP_[SET|SAVE]..

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 > > @@

Re: [Xen-devel] [PATCH v2 9/9] tmem: Batch and squash XEN_SYSCTL_TMEM_OP_SAVE_GET_POOL_[FLAGS, NPAGES, UUID] in one sub-call: XEN_SYSCTL_TMEM_OP_GET_POOLS.

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 >

[Xen-devel] [xen-unstable test] 101225: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH v2 8/9] tmem/xc_tmem_control: Rename 'arg1' to 'len' and 'arg2' to arg.

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'. >

Re: [Xen-devel] [PATCH v2 7/9] tmem: Unify XEN_SYSCTL_TMEM_OP_[[SAVE_[BEGIN|END]|RESTORE_BEGIN]

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

Re: [Xen-devel] [PATCH v2 6/9] tmem/libxc: Squash XEN_SYSCTL_TMEM_OP_[SET|SAVE]..

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, >

Re: [Xen-devel] Adding new custom devices to Xen via QEMU

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

[Xen-devel] [xen-unstable-smoke test] 101227: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH v2 4/9] tmem: Move client weight, frozen, live_migrating, and compress

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

Re: [Xen-devel] [PATCH v2 5/9] tmem/sysctl: Add union in struct xen_sysctl_tmem_op

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

Re: [Xen-devel] [PATCH v2 3/9] tmem: Delete deduplication (and tze) code.

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

Re: [Xen-devel] [PATCH v2 6/9] tmem/libxc: Squash XEN_SYSCTL_TMEM_OP_[SET|SAVE]..

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-devel] [PATCH v2 1/9] libxc/tmem/restore: Remove call to XEN_SYSCTL_TMEM_OP_SAVE_GET_VERSION

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

[Xen-devel] [PATCH v2 4/9] tmem: Move client weight, frozen, live_migrating, and compress

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-devel] [PATCH v2 2/9] tmem: Retire XEN_SYSCTL_TMEM_OP_[SET_CAP|SAVE_GET_CLIENT_CAP]

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].."

[Xen-devel] [PATCH v2 3/9] tmem: Delete deduplication (and tze) code.

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

[Xen-devel] [PATCH v2 6/9] tmem/libxc: Squash XEN_SYSCTL_TMEM_OP_[SET|SAVE]..

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-devel] [PATCH v2 7/9] tmem: Unify XEN_SYSCTL_TMEM_OP_[[SAVE_[BEGIN|END]|RESTORE_BEGIN]

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

[Xen-devel] [PATCH v2 8/9] tmem/xc_tmem_control: Rename 'arg1' to 'len' and 'arg2' to arg.

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

[Xen-devel] [PATCH v2] Tmem cleanups/improvements for v4.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

Re: [Xen-devel] [Resend PATCH 2/2] Xen/timer: Process softirq during dumping timer info

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

Re: [Xen-devel] [Patch] x86emul: simplify prefix handling for VMFUNC

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

Re: [Xen-devel] [Resend PATCH 1/2] Xen/Keyhandler: Make keyhandler always run in tasklet

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?

Re: [Xen-devel] [PATCH v2 29/30] xen/x86: allow PVHv2 to perform foreign memory mappings

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

Re: [Xen-devel] [PATCH v2 06/30] x86/paging: introduce paging_set_allocation

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

Re: [Xen-devel] [PATCH v2 04/30] xen/x86: allow calling {sh/hap}_set_allocation with the idle domain

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

Re: [Xen-devel] [PATCH v2 04/30] xen/x86: allow calling {sh/hap}_set_allocation with the idle domain

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:

Re: [Xen-devel] [PATCH v1 08/12] tmem: Handle 'struct tmem_info' as a seperate field in the

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

Re: [Xen-devel] [PATCH v2 03/30] xen/x86: fix parameters and return value of *_set_allocation functions

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

[Xen-devel] [xen-unstable-smoke test] 101226: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH] trace: Fix incorrect number of pages used for trace metadata

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 >>>

Re: [Xen-devel] [PATCH] trace: Fix incorrect number of pages used for trace metadata

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

Re: [Xen-devel] [PATCH v2 10/10] xl: allow to set the ratelimit value online for Credit2

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

Re: [Xen-devel] [PATCH v2 10/10] xl: allow to set the ratelimit value online for Credit2

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) >

Re: [Xen-devel] [PATCH v2 15/30] xen/x86: populate PVHv2 Dom0 physical memory map

>>> 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

Re: [Xen-devel] [PATCH] svm/emulate: remove duplicated const specifier

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

[Xen-devel] [PATCH] svm/emulate: remove duplicated const specifier

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

Re: [Xen-devel] [PATCH v2 10/30] xen/x86: allow the emulated APICs to be enbled for the hardware domain

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) && >

Re: [Xen-devel] [PATCH 22/24] xen: credit2: "relax" CSCHED2_MAX_TIMER

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

Re: [Xen-devel] [PATCH v3 0/2] sched: Credit1 and Credit2 improvements... but *NO* soft-affinity for Credit2!

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 > >

Re: [Xen-devel] [PATCH v2 14/30] xen/mm: add a ceil sufix to current page calculation routine

>>> 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

Re: [Xen-devel] [PATCH v3 1/2] xen: credit2: implement yield()

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

Re: [Xen-devel] [PATCH v2 09/30] x86/vtd: fix and simplify mapping RMRR regions

>>> 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,

Re: [Xen-devel] [PATCH v2 12/30] xen/x86: make print_e820_memory_map global

>>> 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

Re: [Xen-devel] [PATCH v2 11/30] xen/x86: split Dom0 build into PV and PVHv2

>>> 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. > >

Re: [Xen-devel] [PATCH v2 09/30] x86/vtd: fix and simplify mapping RMRR regions

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; > >> > + > >> > +

Re: [Xen-devel] [PATCH v3] SVM: use generic instruction decoding

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) > +{ >

Re: [Xen-devel] [PATCH v3] SVM: use generic instruction decoding

>>> 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 (

Re: [Xen-devel] [PATCH v2 2/2] hvmloader, pci: Don't try to relocate memory if 64-bit BAR is bigger than ~2GB

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,

Re: [Xen-devel] [PATCH v1 08/12] tmem: Handle 'struct tmem_info' as a seperate field in the

>>> 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

Re: [Xen-devel] [PATCH v3] SVM: use generic instruction decoding

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

Re: [Xen-devel] [PATCH v3] SVM: use generic instruction decoding

>>> 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 (

Re: [Xen-devel] [PATCH] trace: Fix incorrect number of pages used for trace metadata

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

Re: [Xen-devel] [PATCH] trace: Fix incorrect number of pages used for trace metadata

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

Re: [Xen-devel] [PATCH v2 0/2] Convert to new CPU hotplug framework

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

Re: [Xen-devel] [PATCH v3] SVM: use generic instruction decoding

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 )

Re: [Xen-devel] [PATCH v3 0/3] xen/pciback: support driver_override

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

Re: [Xen-devel] [PATCH] trace: Fix incorrect number of pages used for trace metadata

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

Re: [Xen-devel] [PATCH] xen: Remove event channel notification through Xen PCI platform device

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

Re: [Xen-devel] [PATCH v3] SVM: use generic instruction decoding

>>> 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 +

Re: [Xen-devel] [PATCH v3] SVM: use generic instruction decoding

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, > -

Re: [Xen-devel] [PATCH v1 08/12] tmem: Handle 'struct tmem_info' as a seperate field in the

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

Re: [Xen-devel] Adding new custom devices to Xen via QEMU

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

[Xen-devel] [PATCH v3 2/2] xen: tracing: add trace records for schedule and rate-limiting.

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

[Xen-devel] [PATCH v3 0/2] sched: Credit1 and Credit2 improvements... but *NO* soft-affinity for Credit2!

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

[Xen-devel] [PATCH v3 1/2] xen: credit2: implement yield()

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

Re: [Xen-devel] [PATCH v2] x86/32on64: don't modify guest descriptors without need

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

Re: [Xen-devel] [PATCH v2 00/10] sched: Credit1 and Credit2 improvements... but *NO* soft-affinity for Credit2!

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

Re: [Xen-devel] [PATCH v2 3/4] x86emul: support RTM instructions

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

Re: [Xen-devel] [PATCH v2 00/10] sched: Credit1 and Credit2 improvements... but *NO* soft-affinity for Credit2!

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- >>>

[Xen-devel] [xen-unstable-smoke test] 101224: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH v2 00/10] sched: Credit1 and Credit2 improvements... but *NO* soft-affinity for Credit2!

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

Re: [Xen-devel] [PATCH v1 02/12] tmem: Retire XEN_SYSCTL_TMEM_OP_[SET_CAP|SAVE_GET_CLIENT_CAP]

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

Re: [Xen-devel] [PATCH v2 05/10] xen: credit2: implement yield()

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 > >

Re: [Xen-devel] Adding new custom devices to Xen via QEMU

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

Re: [Xen-devel] [PATCH v2 00/10] sched: Credit1 and Credit2 improvements... but *NO* soft-affinity for Credit2!

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

[Xen-devel] [PATCH v2] x86/32on64: don't modify guest descriptors without need

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

Re: [Xen-devel] Adding new custom devices to Xen via QEMU

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

Re: [Xen-devel] [PATCH v2 08/10] libxl: fix coding style of credit1 parameters related functions

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, >>>

Re: [Xen-devel] [PATCH v2 09/30] x86/vtd: fix and simplify mapping RMRR regions

>>> 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

Re: [Xen-devel] [PATCH v2 2/4] x86emul: consolidate segment register handling

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

Re: [Xen-devel] [PATCH v2 1/4] x86emul: support UMIP

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.

[Xen-devel] [PATCH v2 4/4] x86emul: conditionally clear BNDn for branches

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

[Xen-devel] [PATCH v2 3/4] x86emul: support RTM instructions

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. ---

Re: [Xen-devel] [PATCH v2 06/10] xen: tracing: add trace records for schedule and rate-limiting.

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 >

[Xen-devel] [PATCH v2 2/4] x86emul: consolidate segment register handling

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 --- v2: s/store_seg/store_selector/g. Re-base. ---

[Xen-devel] [PATCH v2 1/4] x86emul: support UMIP

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 --- v2: s/is_umip/umip_active/g. Fix a coding style issue. ---

[Xen-devel] [PATCH v2 0/4] x86: further insn emulator improvements

1: support UMIP 2: consolidate segment register handling 3: support RTM instructions 4: conditionally clear BNDn for branches Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org

  1   2   >