On 07/07/2016 09:45 AM, anshul.makkar.anshul.mak...@citrix.com wrote:
From: Anshul Makkar
This patch resolves the following permission denied scenarios while creating
new domU :
avc: denied { setdomainhandle } for domid=0 target=1
scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:d
Wei Liu:
>> diff --git a/tools/configure.ac b/tools/configure.ac
>> index 8704927..e08fa8e 100644
>> --- a/tools/configure.ac
>> +++ b/tools/configure.ac
>> @@ -437,6 +437,7 @@ AS_IF([test "x$systemd" = "xy"], [
>> hotplug/Linux/systemd/xenconsoled.service
>> hotplug/Linux/systemd/xendoma
On 07/07/2016 06:30 AM, Jan Beulich wrote:
On 05.07.16 at 19:44, wrote:
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -762,6 +762,13 @@ static inline void flask_init(void)
}
#endif
+#ifdef CONFIG_XSM_POLICY
+extern const unsigned char xsm_init_policy[];
+extern const int xsm_ini
On Thu, Jul 07, 2016 at 02:09:32PM +, Rusty Bird wrote:
> A dedicated Xen driver domain init service starts "xl devd" in domU. But
> currently, it is only supplied in the form of a SysV init script, which
> systemd users run through a backward compatiblity wrapper automatically
> generated by s
Wei Liu:
> While I understand it might be necessary to have a dedicated service
> file for xendriverdomain, I can't seem to be able to figure out the
> rationale from the commit message.
>
> After thinking a bit harder, may I suggest commit message like this (and
> please correct me if I'm wrong):
A dedicated Xen driver domain init service starts "xl devd" in domU. But
currently, it is only supplied in the form of a SysV init script, which
systemd users run through a backward compatiblity wrapper automatically
generated by systemd-sysv-generator. This patch adds a (naturally more
lightweight
On 07/07/16 14:59, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was
> Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"):
>> On 07/07/16 12:10, Lars Kurth wrote:
>>> @Andrew: would something like test/xtf.git work
> I would live with that.
>
>> It would
On 07/07/16 14:59, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was
> Re: [PATCH 0/2] xtf: add launcher (+1 bugfix)"):
>> On 07/07/16 12:10, Lars Kurth wrote:
>>> @Andrew: would something like test/xtf.git work
>
> I would live with that.
>
>> It w
Andrew Cooper writes ("Re: [Xen-devel] xenbits "official" repo for XTF (was Re:
[PATCH 0/2] xtf: add launcher (+1 bugfix)"):
> On 07/07/16 12:10, Lars Kurth wrote:
> > @Andrew: would something like test/xtf.git work
I would live with that.
> It would, although given a straight choice I would pre
From: Anshul Makkar
This patch resolves the following permission denied scenarios while creating
new domU :
avc: denied { setdomainhandle } for domid=0 target=1
scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:domU_t
tclass=domain
avc: denied { settime } for domid=0 target=1 sco
On Thu, Jul 07, 2016 at 02:14:53PM +0100, Julien Grall wrote:
>
>
> On 07/07/16 13:43, Lars Kurth wrote:
> >
> >>On 7 Jul 2016, at 12:28, Wei Liu wrote:
> >>
> >>Also CC Lars.
> >>
> >>On Mon, Jul 04, 2016 at 12:12:52PM +0100, Julien Grall wrote:
> >>>(CC Wei for the release part)
> >>>
> >>>Hi
>>> On 07.07.16 at 15:22, wrote:
> On 07/07/16 14:13, David Vrabel wrote:
>> On 07/07/16 13:23, Jan Beulich wrote:
>> On 07.07.16 at 14:17, wrote:
On 07/07/16 13:09, Jan Beulich wrote:
On 07.07.16 at 13:36, wrote:
>> On 07/07/16 08:32, Jan Beulich wrote:
>>> We must not
On Thu, 7 Jul 2016, Andrew Cooper wrote:
> On 07/07/16 14:17, Lars Kurth wrote:
> >> On 7 Jul 2016, at 14:14, Julien Grall wrote:
> >>
> >>
> >>
> >> On 07/07/16 13:43, Lars Kurth wrote:
> On 7 Jul 2016, at 12:28, Wei Liu wrote:
>
> Also CC Lars.
>
> On Mon, Jul 04, 2016
On 07/07/16 14:13, David Vrabel wrote:
> On 07/07/16 13:23, Jan Beulich wrote:
> On 07.07.16 at 14:17, wrote:
>>> On 07/07/16 13:09, Jan Beulich wrote:
>>> On 07.07.16 at 13:36, wrote:
> On 07/07/16 08:32, Jan Beulich wrote:
>> We must not skip the transaction_end() call for a fai
On 07/07/16 14:17, Lars Kurth wrote:
>> On 7 Jul 2016, at 14:14, Julien Grall wrote:
>>
>>
>>
>> On 07/07/16 13:43, Lars Kurth wrote:
On 7 Jul 2016, at 12:28, Wei Liu wrote:
Also CC Lars.
On Mon, Jul 04, 2016 at 12:12:52PM +0100, Julien Grall wrote:
> (CC Wei for the
> On 7 Jul 2016, at 14:14, Julien Grall wrote:
>
>
>
> On 07/07/16 13:43, Lars Kurth wrote:
>>
>>> On 7 Jul 2016, at 12:28, Wei Liu wrote:
>>>
>>> Also CC Lars.
>>>
>>> On Mon, Jul 04, 2016 at 12:12:52PM +0100, Julien Grall wrote:
(CC Wei for the release part)
Hi Dirk,
On 07/07/16 13:43, Lars Kurth wrote:
On 7 Jul 2016, at 12:28, Wei Liu wrote:
Also CC Lars.
On Mon, Jul 04, 2016 at 12:12:52PM +0100, Julien Grall wrote:
(CC Wei for the release part)
Hi Dirk,
On 04/07/16 07:51, Dirk Behme wrote:
Signed-off-by: Dirk Behme
Thank you for adding support
On 07/07/16 13:23, Jan Beulich wrote:
On 07.07.16 at 14:17, wrote:
>> On 07/07/16 13:09, Jan Beulich wrote:
>> On 07.07.16 at 13:36, wrote:
On 07/07/16 08:32, Jan Beulich wrote:
> We must not skip the transaction_end() call for a failed
> XS_TRANSACTION_START. The removed co
On 07/07/16 12:03, Dario Faggioli wrote:
> On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
>> On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
>> wrote:
>>>
>>> in both xenalyze and formats (for xentrace_format).
>>>
>>> In particular, in xenalyze, now that we have the precision
>>> of the
> On 7 Jul 2016, at 12:28, Wei Liu wrote:
>
> Also CC Lars.
>
> On Mon, Jul 04, 2016 at 12:12:52PM +0100, Julien Grall wrote:
>> (CC Wei for the release part)
>>
>> Hi Dirk,
>>
>> On 04/07/16 07:51, Dirk Behme wrote:
>>> Signed-off-by: Dirk Behme
>>
>> Thank you for adding support of a new
On 07/07/16 09:33, Jan Beulich wrote:
> ... over list_for_each_safe() when list modification if accompanied by
> breaking out of the loop.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
> ---
> drivers/xen/xenbus/xenbus_dev_frontend.c |4 ++--
> 1 file changed, 2 insertions(+),
On 07/07/16 10:01, Jan Beulich wrote:
> Only a positive return value indicates success.
>
> Signed-off-by: Jan Beulich
Acked-by: Juergen Gross
> ---
> drivers/xen/xen-scsiback.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- 4.7-rc6-xenbus_scanf.orig/drivers/xen/xen-s
On 07/07/16 10:01, Jan Beulich wrote:
> Only a positive return value indicates success.
>
> Signed-off-by: Jan Beulich
Acked-by: Juergen Gross
> ---
> drivers/scsi/xen-scsifront.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- 4.7-rc6-xenbus_scanf.orig/drivers/scsi/xe
>>> On 07.07.16 at 14:17, wrote:
> On 07/07/16 13:09, Jan Beulich wrote:
> On 07.07.16 at 13:36, wrote:
>>> On 07/07/16 08:32, Jan Beulich wrote:
We must not skip the transaction_end() call for a failed
XS_TRANSACTION_START. The removed code fragment got introduced by
commit 02
On Thu, Jul 07, 2016 at 06:00:25AM -0600, Jan Beulich wrote:
> >>> On 07.07.16 at 12:38, wrote:
> > On Thu, Jul 07, 2016 at 01:35:54PM +0300, Jarkko Sakkinen wrote:
> >> On Thu, Jul 07, 2016 at 02:04:00AM -0600, Jan Beulich wrote:
> >> > Only a positive return value indicates success.
> >> >
> >>
>>> On 07.07.16 at 12:55, wrote:
>> -Original Message-
>> From: netdev-ow...@vger.kernel.org [mailto:netdev-
>> ow...@vger.kernel.org] On Behalf Of David Vrabel
>> Sent: 07 July 2016 11:45
>> To: Wei Liu; David Vrabel
>> Cc: xen-de...@lists.xenproject.org; Jan Beulich; net...@vger.kernel.
On 07/07/16 13:09, Jan Beulich wrote:
On 07.07.16 at 13:36, wrote:
>> On 07/07/16 08:32, Jan Beulich wrote:
>>> We must not skip the transaction_end() call for a failed
>>> XS_TRANSACTION_START. The removed code fragment got introduced by
>>> commit 027bd7e899 ("xen/xenbus: Avoid synchronous
>>> On 07.07.16 at 13:36, wrote:
> On 07/07/16 08:32, Jan Beulich wrote:
>> We must not skip the transaction_end() call for a failed
>> XS_TRANSACTION_START. The removed code fragment got introduced by
>> commit 027bd7e899 ("xen/xenbus: Avoid synchronous wait on XenBus
>> stalling shutdown/restart
>>> On 07.07.16 at 13:12, wrote:
> The better clean-up is to remove xenbus_write() in favour of
> xenbus_printf() everywhere (especially since one of your "cleanups" made
> it worse).
I don't think I've seen any reply indicating something has got made
worse. The fact that in one case I left the x
On Sun, Jul 03, 2016 at 03:33:01AM +, Rusty Bird wrote:
> Uses ConditionVirtualization=xen, which evaluates to false in dom0 since
> systemd 214 (released 2014-06-11). An alternative would be this line:
> ExecStartPre=/bin/sh -c "! grep -q control_d /proc/xen/capabilities"
>
> (Please rerun au
>>> On 07.07.16 at 12:38, wrote:
> On Thu, Jul 07, 2016 at 01:35:54PM +0300, Jarkko Sakkinen wrote:
>> On Thu, Jul 07, 2016 at 02:04:00AM -0600, Jan Beulich wrote:
>> > Only a positive return value indicates success.
>> >
>> > Signed-off-by: Jan Beulich
>>
>> Reviewed-by: Jarkko Sakkinen
>
>
On Thu, Jun 30, 2016 at 05:40:23PM +0100, Andrew Cooper wrote:
> When scripting, it is much more convenient to use:
>
> [root@fusebot ~]# xl info xen_version
> 4.8-unstable
>
> than to construct some sed/awk/other to parse:
>
> [root@fusebot ~]# xl info
> ...
> xen_version
>>> On 04.07.16 at 17:13, wrote:
In case this (or a variant thereof) is to be used despite the earlier
voiced concerns, a couple of mechanical comments:
> +static const char *loglvl_to_str(int lvl)
> +{
> +unsigned int i;
> +
> +if ( lvl < LOG_LEVEL_MIN || lvl > LOG_LEVEL_MAX )
> +
On 07/07/16 08:32, Jan Beulich wrote:
> We must not skip the transaction_end() call for a failed
> XS_TRANSACTION_START. The removed code fragment got introduced by
> commit 027bd7e899 ("xen/xenbus: Avoid synchronous wait on XenBus
> stalling shutdown/restart") without its description really indica
Also CC Lars.
On Mon, Jul 04, 2016 at 12:12:52PM +0100, Julien Grall wrote:
> (CC Wei for the release part)
>
> Hi Dirk,
>
> On 04/07/16 07:51, Dirk Behme wrote:
> >Signed-off-by: Dirk Behme
>
> Thank you for adding support of a new board in Xen.
>
> During the last hackathon, we discussed ab
On 07/07/16 12:10, Lars Kurth wrote:
>> On 6 Jul 2016, at 15:22, Konrad Rzeszutek Wilk
>> wrote:
>>
>>> Looking at the above, it occurs to me that, this whole area seems to be a
>>> little inconsistent anyway and could do with a little house-keeping. We
>>> have
>>> - osstest.git
>>> - there also
On 07/07/16 08:23, Jan Beulich wrote:
> Inability to locate a user mode specified transaction ID should not
> lead to a kernel crash. For other than XS_TRANSACTION_START also
> don't issue anything to xenbus if the specified ID doesn't match that
> of any active transaction.
Applied to for-linus-4
On 07/07/16 09:00, Jan Beulich wrote:
> ... as being the simpler variant.
It's really annoying that all these related cleanups where not in the
same thread. Don't do this again, please.
The better clean-up is to remove xenbus_write() in favour of
xenbus_printf() everywhere (especially since one o
> On 6 Jul 2016, at 15:22, Konrad Rzeszutek Wilk wrote:
>
>> Looking at the above, it occurs to me that, this whole area seems to be a
>> little inconsistent anyway and could do with a little house-keeping. We
>> have
>> - osstest.git
>> - there also is osstest/*.git which seems to be odd and se
On Thu, 2016-07-07 at 10:36 +0100, George Dunlap wrote:
> On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
> wrote:
> >
> > in both xenalyze and formats (for xentrace_format).
> >
> > In particular, in xenalyze, now that we have the precision
> > of the fixed point load values in the tracepoint,
On Mon, 2016-06-20 at 02:13 -0600, Jan Beulich wrote:
> > > > On 18.06.16 at 01:12, wrote:
> > @@ -680,8 +677,8 @@ __update_svc_load(const struct scheduler *ops,
> > delta = now - svc->load_last_update;
> > if ( unlikely(delta < 0) )
> > {
> > -d2printk("%s:
On Thu, Jul 07, 2016 at 03:42:02AM -0600, Jan Beulich wrote:
> >>> On 07.07.16 at 11:32, wrote:
> > On Thu, Jul 07, 2016 at 01:40:54AM -0600, Jan Beulich wrote:
> >> The ioctl can be called prior to full device setup having completed.
> >>
> >> Signed-off-by: Jan Beulich
> >> ---
> >> drivers/b
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of David Vrabel
> Sent: 07 July 2016 11:45
> To: Wei Liu; David Vrabel
> Cc: xen-de...@lists.xenproject.org; Jan Beulich; net...@vger.kernel.org
> Subject: Re: [Xen-devel] [PATCH] xe
On Thu, 2016-07-07 at 03:18 -0600, Jan Beulich wrote:
> > > > On 07.07.16 at 11:09, wrote:
> > > Oh, okay - I agree on those two parts then. But the question on
> > > the
> > > usefulness of absolute vs relative times remains.
> > What is the usefulness of printing the relative time? If you have
Hi Dirk,
On 07/07/16 11:39, Dirk Behme wrote:
On 06.07.2016 16:21, Julien Grall wrote:
On 06/07/16 15:03, Dirk Behme wrote:
On 06.07.2016 15:17, Julien Grall wrote:
Hi Dirk,
On 06/07/16 07:33, Dirk Behme wrote:
Could you share the U-Boot commands how you load and esp. start Xen?
For
loading
On 07/07/16 11:35, Wei Liu wrote:
> On Thu, Jul 07, 2016 at 10:58:16AM +0100, David Vrabel wrote:
>> On 07/07/16 08:57, Jan Beulich wrote:
>>> Only a positive return value indicates success.
>>
>> This is not correct.
>>
>
> Do you mean the commit message is not correct or the code is not
> correc
> -Original Message-
> From: Paul Durrant
> Sent: 07 July 2016 11:41
> To: Wei Liu; David Vrabel
> Cc: Jan Beulich; Wei Liu; xen-de...@lists.xenproject.org;
> net...@vger.kernel.org
> Subject: RE: [Xen-devel] [PATCH] xen-netback: correct return value checks
> on xenbus_scanf()
>
> > -O
On 07/07/16 11:26, David Vrabel wrote:
> On 07/07/16 09:06, Jan Beulich wrote:
>> ... as being the simpler variant.
> [...]
>> --- 4.7-rc6-prefer-xenbus_write.orig/drivers/block/xen-blkback/xenbus.c
>> +++ 4.7-rc6-prefer-xenbus_write/drivers/block/xen-blkback/xenbus.c
>> @@ -617,9 +617,9 @@ static
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Wei Liu
> Sent: 07 July 2016 11:35
> To: David Vrabel
> Cc: Jan Beulich; Wei Liu; xen-de...@lists.xenproject.org;
> net...@vger.kernel.org
> Subject: Re: [Xen-devel] [PATCH] xen-n
Hi Julien,
On 06.07.2016 16:21, Julien Grall wrote:
On 06/07/16 15:03, Dirk Behme wrote:
On 06.07.2016 15:17, Julien Grall wrote:
Hi Dirk,
On 06/07/16 07:33, Dirk Behme wrote:
Could you share the U-Boot commands how you load and esp. start Xen?
For
loading you use TFTP? How do you start Xe
On Thu, Jul 07, 2016 at 02:04:00AM -0600, Jan Beulich wrote:
> Only a positive return value indicates success.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Jarkko Sakkinen
/Jarkko
> ---
> drivers/char/tpm/xen-tpmfront.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- 4.7-r
>>> On 04.07.16 at 17:13, wrote:
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -139,6 +139,20 @@ custom_param("guest_loglvl", parse_guest_loglvl);
>
> static atomic_t print_everything = ATOMIC_INIT(0);
>
> +struct log_level {
> +const char *str;
> +unsigne
On Thu, Jul 07, 2016 at 01:35:54PM +0300, Jarkko Sakkinen wrote:
> On Thu, Jul 07, 2016 at 02:04:00AM -0600, Jan Beulich wrote:
> > Only a positive return value indicates success.
> >
> > Signed-off-by: Jan Beulich
>
> Reviewed-by: Jarkko Sakkinen
Applied. Should this be CC'd to stable or not?
On Thu, Jul 07, 2016 at 10:58:16AM +0100, David Vrabel wrote:
> On 07/07/16 08:57, Jan Beulich wrote:
> > Only a positive return value indicates success.
>
> This is not correct.
>
Do you mean the commit message is not correct or the code is not
correct? If it is the formal, do you have any sugg
The function flush_tlb is called to invalidate the TLBs for the current
domain when the stage-2 page tables are modified.
On ARMv8, the instruction "tlbi vmalle1is" (resp. "tlbi vmalle1") will
invalidate stage 1 entries associated to the current VMID (see D4-1811 in
ARM DDI 0487A.j).
Given that a
>>> On 05.07.16 at 19:44, wrote:
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -762,6 +762,13 @@ static inline void flask_init(void)
> }
> #endif
>
> +#ifdef CONFIG_XSM_POLICY
> +extern const unsigned char xsm_init_policy[];
> +extern const int xsm_init_policy_size;
unsigne
On Wed, 2016-07-06 at 17:10 +0100, George Dunlap wrote:
> On Mon, Jun 20, 2016 at 8:56 AM, Jan Beulich
> wrote:
> >
> > > > > On 18.06.16 at 01:12, wrote:
> > > Yet another situation very similar to 779511f4bf5ae
> > > ("sched: avoid races on time values read from NOW()").
> > >
> > > In fact,
On Wed, 2016-07-06 at 17:02 +0100, George Dunlap wrote:
> On Sat, Jun 18, 2016 at 12:11 AM, Dario Faggioli
> wrote:
> >
> > In fact, it has the same signature of csched2_cpu_pick,
> > which also is its uniqe caller.
> >
> > Signed-off-by: Dario Faggioli
> Reviewed-by: George Dunlap
>
> And qu
On Wed, 2016-07-06 at 16:41 +0100, George Dunlap wrote:
> On Sat, Jun 18, 2016 at 12:11 AM, Dario Faggioli
>
> > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> > index a38a63d..a6645a2 100644
> > --- a/xen/common/sched_credit.c
> > +++ b/xen/common/sched_credit.c
> > @@ -1819
On 07/07/16 09:06, Jan Beulich wrote:
> ... as being the simpler variant.
[...]
> --- 4.7-rc6-prefer-xenbus_write.orig/drivers/block/xen-blkback/xenbus.c
> +++ 4.7-rc6-prefer-xenbus_write/drivers/block/xen-blkback/xenbus.c
> @@ -617,9 +617,9 @@ static int xen_blkbk_probe(struct xenbus
>
On 07/05/2016 04:44 PM, Jan Beulich wrote:
On 05.07.16 at 17:34, wrote:
>> On Thu, Jun 30, 2016 at 03:10:11AM -0600, Jan Beulich wrote:
>> On 29.06.16 at 18:27, wrote:
On 29/06/16 17:19, Vitaly Kuznetsov wrote:
> To explain better what I'm trying to suggest here please take a lo
On Mon, 2016-06-20 at 01:48 -0600, Jan Beulich wrote:
> > > > On 18.06.16 at 01:11, wrote:
> > --- a/xen/common/sched_credit.c
> > +++ b/xen/common/sched_credit.c
> > @@ -1819,24 +1819,24 @@ csched_schedule(
> > else
> > snext = csched_load_balance(prv, cpu, snext,
> > &ret.migrated)
On 07/07/16 10:57, Jan Beulich wrote:
On 07.07.16 at 11:46, wrote:
Anyway, I think this patch was in a good state (though few registers
were needed clarification). Assuming it is ok to break the compatibility
later on, I will not oppose to have a reduce set.
Iirc we did bump that interface
>>> On 07.07.16 at 11:55, wrote:
> On 07/07/16 08:57, Jan Beulich wrote:
>> --- 4.7-rc6-prefer-xenbus_scanf.orig/drivers/net/xen-netback/xenbus.c
>> +++ 4.7-rc6-prefer-xenbus_scanf/drivers/net/xen-netback/xenbus.c
>> @@ -842,16 +842,16 @@ static int connect_ctrl_ring(struct back
>> unsigned i
On 05/07/16 19:37, Tamas K Lengyel wrote:
+#if defined(__arm__) || defined(__aarch64__)
+case VM_EVENT_REASON_PRIVILEGED_CALL:
+{
+const struct vm_event_regs_arm *in_regs =
&req.data.regs.arm;
+struct vm_event_regs_arm *out_re
>>> On 07.07.16 at 11:42, wrote:
> On 07/07/16 09:48, Jan Beulich wrote:
>> Only a positive return value indicates success.
>
> Hmm, I'm not convinced on this change (and the similar others as
> well). From xenbus.h:
>
> /* Single read and scanf: returns -errno or num scanned if > 0. */
>
> The
flight 96743 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96743/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 94748
test-amd64-amd64-
>>> On 07.07.16 at 11:44, wrote:
> On Thu, Jul 07, 2016 at 02:06:33AM -0600, Jan Beulich wrote:
>> ... as being the simpler variant.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> drivers/block/xen-blkfront.c |7 +++
>> 1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> --- 4.7-rc6-pref
On Wed, 2016-07-06 at 18:33 +0100, anshul.mak...@citrix.com wrote:
> From: Anshul Makkar
>
Hey, Anshul,
Thanks for doing this!
> Rate limit assures that a vcpu will execute for a minimum amount of
> time before
> being put at the back of a queue or being preempted by higher
> priority thread.
>
On 07/07/16 08:57, Jan Beulich wrote:
> Only a positive return value indicates success.
This is not correct.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
>>> On 07.07.16 at 11:46, wrote:
> Anyway, I think this patch was in a good state (though few registers
> were needed clarification). Assuming it is ok to break the compatibility
> later on, I will not oppose to have a reduce set.
Iirc we did bump that interface version already after the tree g
On 07/07/16 08:59, Jan Beulich wrote:
> Only a positive return value indicates success.
This checks were already correct.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 07/07/16 08:57, Jan Beulich wrote:
> ... for single items being collected: It is more typesafe (as the
> compiler can check format string and to-be-written-to variable match)
> and requires one less parameter to be passed.
Do not split commit messages between the subject and the body in this
wa
On 07/07/16 10:45, Roger Pau Monne wrote:
> On Thu, Jul 07, 2016 at 01:38:58AM -0600, Jan Beulich wrote:
>> The functions such get passed to have been taking pointers to const
>> since at least 2.6.16.
>>
>> Signed-off-by: Jan Beulich
> Acked-by: Roger Pau Monné
>
> Although the wording in the co
>>> On 07.07.16 at 11:40, wrote:
> On 07/07/16 08:35, Jan Beulich wrote:
>> There's no reason why this would need to be limited to x86-64.
>
> Did you test it?
Well, its original version in the 2.6.18 tree did get enabled for 32-bit
use in the course of forward porting those patches, and things
On 07/07/16 08:48, Jan Beulich wrote:
>
> Signed-off-by: Jan Beulich
> ---
> drivers/video/fbdev/xen-fbfront.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- 4.7-rc6-xenbus_scanf.orig/drivers/video/fbdev/xen-fbfront.c
> +++ 4.7-rc6-xenbus_scanf/drivers/video/fbdev/xen-fb
On 07/07/16 09:23, Jan Beulich wrote:
On 06.07.16 at 21:12, wrote:
On Wed, Jul 6, 2016 at 12:04 PM, Julien Grall wrote:
On 05/07/16 19:37, Tamas K Lengyel wrote:
+void vm_event_fill_regs(vm_event_request_t *req)
+{
+const struct cpu_user_regs *regs = guest_cpu_user_regs();
+
+re
On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
wrote:
> as all the accesses to both the masks and the flags are
> serialized by the runqueues locks already.
>
> Signed-off-by: Dario Faggioli
Acked-by: George Dunlap
This one doesn't apply without 10/19, so will have to be resent.
-George
>
On Thu, Jul 07, 2016 at 01:38:58AM -0600, Jan Beulich wrote:
> The functions such get passed to have been taking pointers to const
> since at least 2.6.16.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Although the wording in the commit message looks weird to me, but I'm not a
nati
On Thu, Jul 07, 2016 at 02:06:33AM -0600, Jan Beulich wrote:
> ... as being the simpler variant.
>
> Signed-off-by: Jan Beulich
> ---
> drivers/block/xen-blkfront.c |7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> --- 4.7-rc6-prefer-xenbus_write.orig/drivers/block/xen-blkfr
On Thu, Jul 07, 2016 at 02:06:12AM -0600, Jan Beulich wrote:
> ... as being the simpler variant.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 07/07/16 09:48, Jan Beulich wrote:
> Only a positive return value indicates success.
Hmm, I'm not convinced on this change (and the similar others as
well). From xenbus.h:
/* Single read and scanf: returns -errno or num scanned if > 0. */
There should be no case for xenbus_scanf() returning 0
>>> On 07.07.16 at 11:32, wrote:
> On Thu, Jul 07, 2016 at 01:40:54AM -0600, Jan Beulich wrote:
>> The ioctl can be called prior to full device setup having completed.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> drivers/block/xen-blkfront.c |6 ++
>> 1 file changed, 2 insertions(+), 4 de
On Thu, Jul 07, 2016 at 02:05:46AM -0600, Jan Beulich wrote:
> ... for single items being collected: It is more typesafe (as the
> compiler can check format string and to-be-written-to variable match)
> and requires one less parameter to be passed.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger
On 07/07/16 08:35, Jan Beulich wrote:
> There's no reason why this would need to be limited to x86-64.
Did you test it?
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 07/07/16 08:35, Jan Beulich wrote:
> Many of these operations can take arbitrarily long, which can become a
> problem irrespective of them being exposed to privileged users only.
If this is a concern I would rather see large numbers of mapping
requests processed in smaller batches. This would
On Sat, Jun 18, 2016 at 12:12 AM, Dario Faggioli
wrote:
> in both xenalyze and formats (for xentrace_format).
>
> In particular, in xenalyze, now that we have the precision
> of the fixed point load values in the tracepoint, show both
> the raw value and the (easier to interpreet) percentage.
>
>
On Thu, Jul 07, 2016 at 02:05:21AM -0600, Jan Beulich wrote:
> ... for single items being collected: It is more typesafe (as the
> compiler can check format string and to-be-written-to variable match)
> and requires one less parameter to be passed.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger
On Thu, Jul 07, 2016 at 01:40:54AM -0600, Jan Beulich wrote:
> The ioctl can be called prior to full device setup having completed.
>
> Signed-off-by: Jan Beulich
> ---
> drivers/block/xen-blkfront.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> --- 4.7-rc6-xen.orig/drive
On 07/07/16 10:20, Jan Beulich wrote:
On 07.07.16 at 11:14, wrote:
On 07/07/16 09:35, Jan Beulich wrote:
On 06.07.16 at 18:32, wrote:
On 07/06/2016 12:04 PM, Roger Pau Monné wrote:
On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote:
* Don't set HW_REDUCED_ACPI flags: this fl
>>> On 07.07.16 at 11:14, wrote:
> On 07/07/16 09:35, Jan Beulich wrote:
> On 06.07.16 at 18:32, wrote:
>>> On 07/06/2016 12:04 PM, Roger Pau Monné wrote:
On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote:
> * Don't set HW_REDUCED_ACPI flags: this flag is only available
>>> On 07.07.16 at 11:09, wrote:
> On 07/07/16 08:29, Jan Beulich wrote:
> On 06.07.16 at 18:21, wrote:
>>> On Mon, Jun 20, 2016 at 9:02 AM, Jan Beulich wrote:
>>> On 18.06.16 at 01:12, wrote:
> This really should not happen, but:
> 1. it does happen! Investigation is ongoing h
On Thu, Jul 07, 2016 at 01:38:13AM -0600, Jan Beulich wrote:
> Commit 9d092603cc ("xen-blkback: do not leak mode property") left one
> path unfixed; correct this.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
___
Xen-devel mailing list
Xen
Hi Julien,
On 07/06/2016 07:08 PM, Julien Grall wrote:
> Hi,
>
> On 04/07/16 12:45, Sergej Proskurin wrote:
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -2085,6 +2085,159 @@ bool_t p2m_mem_access_check(paddr_t gpa,
>> vaddr_t gla, const struct npfec npfec)
>
> [...]
>
>> +static
Hi Julien,
On 07/06/2016 08:35 PM, Julien Grall wrote:
>
>
> On 06/07/16 17:35, Tamas K Lengyel wrote:
>> On Wed, Jul 6, 2016 at 10:29 AM, Julien Grall
>> wrote:
>>>
>>>
>>> On 06/07/16 17:05, Tamas K Lengyel wrote:
On Wed, Jul 6, 2016 at 9:54 AM, Julien Grall
wrote:
>
>
On 07/07/16 09:35, Jan Beulich wrote:
On 06.07.16 at 18:32, wrote:
On 07/06/2016 12:04 PM, Roger Pau Monné wrote:
On Tue, Jul 05, 2016 at 03:04:59PM -0400, Boris Ostrovsky wrote:
* Don't set HW_REDUCED_ACPI flags: this flag is only available starting with
ACPI v5
Hm, I still think HW_REDU
On 07/07/16 08:29, Jan Beulich wrote:
On 06.07.16 at 18:21, wrote:
>> On Mon, Jun 20, 2016 at 9:02 AM, Jan Beulich wrote:
>> On 18.06.16 at 01:12, wrote:
This really should not happen, but:
1. it does happen! Investigation is ongoing here:
http://lists.xen.org/archiv
>>> On 07.07.16 at 10:35, wrote:
> On 7/7/2016 11:27 AM, Jan Beulich wrote:
> On 06.07.16 at 17:54, wrote:
>>> --- a/xen/arch/x86/vm_event.c
>>> +++ b/xen/arch/x86/vm_event.c
>>> @@ -96,14 +96,16 @@ void vm_event_register_write_resume(struct vcpu *v,
>>> vm_event_response_t *rsp)
>>> {
>>>
>>> On 06.07.16 at 20:16, wrote:
> @@ -269,8 +269,19 @@ void pci_setup(void)
> if ( ((bar_data & PCI_BASE_ADDRESS_SPACE) ==
>PCI_BASE_ADDRESS_SPACE_MEMORY) ||
> (bar_reg == PCI_ROM_ADDRESS) )
> -mmio_total += bar_sz;
> -
Please re
>>> On 06.07.16 at 19:33, wrote:
> On 07/06/2016 01:03 PM, Julien Grall wrote:
>>
>>
>> On 06/07/16 17:30, Boris Ostrovsky wrote:
>>> On 07/06/2016 12:04 PM, Julien Grall wrote:
Hi Boris,
On 06/07/16 16:50, Boris Ostrovsky wrote:
> On 07/06/2016 07:05 AM, Julien Grall wrote:
>>>
101 - 200 of 245 matches
Mail list logo
