instruction) also allows for this to be true.
Signed-off-by: Jan Beulich
---
arch/x86/entry/entry_64.S | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
--- 4.10-rc6/arch/x86/entry/entry_64.S
+++ 4.10-rc6-x86_64-relax-clobbers/arch/x86/entry/entry_64.S
@@ -212,7 +212,7
The code at .Lrestore_nocheck does not make any assumptions on register
values, so all registers can be clobbered on code paths leading there.
Signed-off-by: Jan Beulich
---
arch/x86/entry/entry_32.S |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.10-rc6/arch/x86/entry/entry_32
A negative return value indicates an error; in fact the function at
present won't ever return zero.
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
---
v2: For consistency with other code don't consider zero an error
(utilizing that xenbus_scanf() at present won
>>> On 15.12.16 at 17:46, wrote:
> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
>> with today's kernel the system isn't coming up when booted as Xen dom0:
>
> Remind me again pls, is dom0 even supposed to load microcode? Isn't the
> hypervisor supposed to apply microcode?
Yes,
>>> On 05.12.16 at 22:32, wrote:
> static inline void sync_core(void)
> {
> - int tmp;
> -
> -#ifdef CONFIG_X86_32
> /*
> - * Do a CPUID if available, otherwise do a jump. The jump
> - * can conveniently enough be the jump around CPUID.
> + * There are quite a few ways
>>> On 29.11.16 at 12:19, wrote:
> On 29/11/16 12:14, Jan Beulich wrote:
>>>>> On 29.11.16 at 11:50, wrote:
>>> --- a/drivers/scsi/xen-scsifront.c
>>> +++ b/drivers/scsi/xen-scsifront.c
>>> @@ -184,8 +184,6 @@ static struct vscsiif_req
>>> On 29.11.16 at 11:50, wrote:
> --- a/drivers/scsi/xen-scsifront.c
> +++ b/drivers/scsi/xen-scsifront.c
> @@ -184,8 +184,6 @@ static struct vscsiif_request *scsifront_pre_req(struct
> vscsifrnt_info *info)
>
> ring_req = RING_GET_REQUEST(&(info->ring), ring->req_prod_pvt);
>
> -
This is a small aid to security, hiding in particular the kernel address
information otherwise available through SGDT/SIDT.
Signed-off-by: Jan Beulich
---
Main question here is whether to limit this to 64-bit (or at least
!CONFIG_VM86) for the time being, or to disable it while running VM86
mode
>>> On 15.11.16 at 12:07, wrote:
> On 15/11/16 11:44, Jan Beulich wrote:
>>>>> On 15.11.16 at 10:55, wrote:
>>> On 15/11/16 10:45, Jan Beulich wrote:
>>>>>>> On 15.11.16 at 09:42, wrote:
>>>>> For a fully dynamical solu
>>> On 15.11.16 at 10:55, wrote:
> On 15/11/16 10:45, Jan Beulich wrote:
>>>>> On 15.11.16 at 09:42, wrote:
>>> For a fully dynamical solution we'd need a way to get a partial
>>> E820 map from the hypervisor (e.g. first 128 entries) in orde
>>> On 15.11.16 at 09:42, wrote:
> On 15/11/16 09:01, Jan Beulich wrote:
>>>>> On 15.11.16 at 08:36, wrote:
>>> On 15/11/16 08:15, Jan Beulich wrote:
>>>>>>> On 15.11.16 at 07:33, wrote:
>>>>> In case I'm right the
>>> On 15.11.16 at 08:36, wrote:
> On 15/11/16 08:15, Jan Beulich wrote:
>>>>> On 15.11.16 at 07:33, wrote:
>>> On 15/11/16 01:11, Alex Thorlton wrote:
>>>> Hey everyone,
>>>>
>>>> We're having problems with large syst
>>> On 15.11.16 at 07:33, wrote:
> On 15/11/16 01:11, Alex Thorlton wrote:
>> Hey everyone,
>>
>> We're having problems with large systems hitting a BUG in
>> xen_memory_setup, due to extra e820 entries created in the
>> XENMEM_machine_memory_map callback. The change in the patch gets things
>>
A negative return value indicates an error; in fact the function at
present won't ever return zero.
Signed-off-by: Jan Beulich
---
v2: For consistency with other code don't consider zero an error
(utilizing that xenbus_scanf() at present won't return zero).
Adjust
>>> On 31.10.16 at 09:28, wrote:
>> > ref = gnttab_claim_grant_reference(&queue->gref_rx_head);
>> > -BUG_ON((signed short)ref < 0);
>> > +WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));
>
>> You really need to cast to plain (or signed) long here -
>>> On 31.10.16 at 06:38, wrote:
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -304,7 +304,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue
> *queue)
> queue->rx_skbs[id] = skb;
>
> ref = gnttab_claim_grant_reference(&queue-
Commit-ID: a2209b742e6cf978b85d4f31a25a269c3d3b062b
Gitweb: http://git.kernel.org/tip/a2209b742e6cf978b85d4f31a25a269c3d3b062b
Author: Jan Beulich
AuthorDate: Mon, 24 Oct 2016 09:00:12 -0600
Committer: Ingo Molnar
CommitDate: Tue, 25 Oct 2016 11:44:25 +0200
x86/build: Fix build with
Don't ignore errors here: Set backend state to unknown when
unsuccessful.
Signed-off-by: Jan Beulich
---
drivers/xen/xenbus/xenbus_probe_frontend.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- 4.9-rc2/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ 4.9-rc2-xenbus-xenbus_
This is more efficient than list_for_each_safe() when list modification
is accompanied by breaking out of the loop.
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
---
v2: Avoid commit message to continue from subject.
---
drivers/xen/xenbus/xenbus_dev_frontend.c |4 ++--
1 file
Older gcc (observed with 4.1.x) doesn't support -Wno-override-init and
also doesn't ignore unknown -Wno-* options.
Fixes: 5e44258d16 "x86/build: Reduce the W=1 warnings noise when compiling x86
syscall tables"
Signed-off-by: Jan Beulich
Cc: Valdis Kletnieks
---
arch/x86/e
>>> On 13.10.16 at 17:46, wrote:
> On 10/13/16 03:08 -0600, Jan Beulich wrote:
>>>>> On 13.10.16 at 10:53, wrote:
>>> On 10/13/16 02:34 -0600, Jan Beulich wrote:
>>>>>>> On 12.10.16 at 18:19, wrote:
>>>>> On Wed, Oct
>>> On 13.10.16 at 17:40, wrote:
> On Thu, Oct 13, 2016 at 2:08 AM, Jan Beulich wrote:
> [..]
>>> I think we can do the similar for Xen, like to lay another pseudo
>>> device on /dev/pmem and do the reservation, like 2. in my previous
>>> reply.
>
>>> On 13.10.16 at 10:53, wrote:
> On 10/13/16 02:34 -0600, Jan Beulich wrote:
>>>>> On 12.10.16 at 18:19, wrote:
>>> On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich wrote:
>>>>>>> On 12.10.16 at 17:42, wrote:
>>>>> On Wed,
>>> On 12.10.16 at 18:19, wrote:
> On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich wrote:
>>>>> On 12.10.16 at 17:42, wrote:
>>> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote:
>>>>>>> On 12.10.16 at 16:58, wrote:
>>>>>
>>> On 12.10.16 at 17:42, wrote:
> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich wrote:
>>>>> On 12.10.16 at 16:58, wrote:
>>> On 10/12/16 05:32 -0600, Jan Beulich wrote:
>>>>>>> On 12.10.16 at 12:33,
>>> On 12.10.16 at 16:58, wrote:
> On 10/12/16 05:32 -0600, Jan Beulich wrote:
>>>>> On 12.10.16 at 12:33, wrote:
>>> The layout is shown as the following diagram.
>>>
>>> +---+---+---+--+--+
>
>>> On 12.10.16 at 12:33, wrote:
> The layout is shown as the following diagram.
>
> +---+---+---+--+--+
> | whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
> | by kernel| Table | Block | for Xen | |
> +-
>>> On 11.10.16 at 17:53, wrote:
> On Tue, Oct 11, 2016 at 6:08 AM, Jan Beulich wrote:
>>>>> Andrew Cooper 10/10/16 6:44 PM >>>
>>>On 10/10/16 01:35, Haozhong Zhang wrote:
>>>> Xen hypervisor needs assistance from Dom0 Linux kernel for f
>>> Andrew Cooper 10/10/16 6:44 PM >>>
>On 10/10/16 01:35, Haozhong Zhang wrote:
>> Xen hypervisor needs assistance from Dom0 Linux kernel for following tasks:
>> 1) Reserve an area on NVDIMM devices for Xen hypervisor to place
>>memory management data structures, i.e. frame table and M2P tabl
>>> On 05.10.16 at 19:09, wrote:
> Early during boot topology_update_package_map() computes
> logical_pkg_ids for all present processors.
>
> Later, when processors are brought up, identify_cpu() updates
> these values based on phys_pkg_id which is a function of
> initial_apicid. On PV guests the
>>> On 04.10.16 at 10:49, wrote:
>> > > If that was the case, everyone should have seen such warnings
>> > > from the day the original patch got introduced.
>> >
>> > Only if they run sparse. Clearly people don't, or we wouldn't have
>> > a history of a ton of such problems, e.g.
>>
>> No - you
>>> On 04.10.16 at 10:02, wrote:
> On Tue, 2016-10-04 at 01:51 -0600, Jan Beulich wrote:
>> >
>> > >
>> > > >
>> > > > On 04.10.16 at 09:33, wrote:
>> > From: Johannes Berg
>> >
>> > __compiletime_ob
>>> On 04.10.16 at 09:33, wrote:
> From: Johannes Berg
>
> __compiletime_object_size() is simply defined to __builtin_object_size()
> which gcc declares with (void *, int type) prototype.
If that was the case, everyone should have seen such warnings from
the day the original patch got introduce
Commit-ID: c907420fdaec78b17f59a6011cb5f9d6051c6a35
Gitweb: http://git.kernel.org/tip/c907420fdaec78b17f59a6011cb5f9d6051c6a35
Author: Jan Beulich
AuthorDate: Mon, 19 Sep 2016 07:27:08 -0600
Committer: Ingo Molnar
CommitDate: Tue, 20 Sep 2016 08:26:41 +0200
locking/rwsem, x86: Drop a
ently), remove it altogether rather than inventing
something like CC_CLOBBER (to accompany CC_SET/CC_OUT).
Signed-off-by: Jan Beulich
--- a/arch/x86/include/asm/rwsem.h
+++ b/arch/x86/include/asm/rwsem.h
@@ -154,7 +154,7 @@ static inline bool __down_write_trylock(
: "+m&
>>> On 15.09.16 at 12:05, wrote:
> On 14/09/16 22:01, Kyle Huey wrote:
>> Xen advertises the underlying support for CPUID faulting but not does pass
>> through writes to the relevant MSR, nor does it virtualize it, so it does
>> not actually work. For now mask off the relevant bit on MSR_PLATFORM_
>>> On 21.08.16 at 21:36, wrote:
>> --- 4.7-rc6-xen.orig/drivers/xen/xenbus/xenbus_dev_frontend.c
>> +++ 4.7-rc6-xen/drivers/xen/xenbus/xenbus_dev_frontend.c
>> @@ -316,11 +316,18 @@ static int xenbus_write_transaction(unsi
>> rc = -ENOMEM;
>> goto o
>>> On 19.08.16 at 16:52, wrote:
> On Thu, Aug 18, 2016 at 04:06:33AM -0600, Jan Beulich wrote:
>> >>> On 17.08.16 at 22:32, wrote:
>> >Looking at the kernel it assumes that WB is ok for 640KB->1MB.
>> >The comment says:
>> >
>>> On 18.08.16 at 12:16, wrote:
> On 18/08/16 11:06, Jan Beulich wrote:
>>>>> On 17.08.16 at 22:32, wrote:
>>>Looking at the kernel it assumes that WB is ok for 640KB->1MB.
>>>The comment says:
>>>" /* Low ISA region i
>>> On 17.08.16 at 22:32, wrote:
> One of the interesting things about XSA 154 fix ("x86: enforce consistent
> cachability of MMIO mappings") is that when certain applications (mcelog)
> are trying to map /dev/mmap and lurk in ISA regions - we get:
DYM /dev/mem ? Most accesses to which are bogus
This should really only be done for XS_TRANSACTION_END messages, or
else at least some of the xenstore-* tools don't work anymore.
Fixes: 0beef634b8 ("xenbus: don't BUG() on user mode induced condition")
Reported-by: Richard Schütz
Cc:
Signed-off-by: Jan Beulich
Teste
This is more efficient than list_for_each_safe() when list modification
is accompanied by breaking out of the loop.
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
---
v2: Avoid commit message to continue from subject.
---
drivers/xen/xenbus/xenbus_dev_frontend.c |4 ++--
1 file
>>> On 02.08.16 at 08:43, wrote:
> --- a/arch/x86/xen/pmu.c
> +++ b/arch/x86/xen/pmu.c
> @@ -547,8 +547,11 @@ void xen_pmu_init(int cpu)
> return;
>
> fail:
> - pr_info_once("Could not initialize VPMU for cpu %d, error %d\n",
> - cpu, err);
> + if (err == -EOPNOTSUPP)
>>> On 13.07.16 at 14:53, wrote:
> On 13/07/16 13:20, Petr Tesarik wrote:
>> If a crash kernel is loaded, do not crash the running domain. This is
>> needed if the kernel is loaded with crash_kexec_post_notifiers, because
>> panic notifiers are run before __crash_kexec() in that case, and this
>>
>>> On 08.07.16 at 16:17, wrote:
> On Fri, Jul 08, 2016 at 06:21:52AM -0600, Jan Beulich wrote:
>> For single items being collected this should be preferred as being more
>> typesafe (as the compiler can check format string and to-be-written-to
>> variable match) and
>>> On 08.07.16 at 14:29, wrote:
> On 08/07/16 13:15, Jan Beulich wrote:
>> As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
>> CPUID[0x8007].EDX[7] anymore, causing the driver to fail to load on
>> both Intel and AMD systems. Doing any ki
For single items being collected this should be preferred as being more
typesafe (as the compiler can check format string and to-be-written-to
variable match) and more efficient (requiring one less parameter to be
passed).
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v2: Avoid
For single items being collected this should be preferred as being more
typesafe (as the compiler can check format string and to-be-written-to
variable match) and more efficient (requiring one less parameter to be
passed).
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v2: Avoid
For single items being collected this should be preferred as being more
typesafe (as the compiler can check format string and to-be-written-to
variable match) and more efficient (requiring one less parameter to be
passed).
Signed-off-by: Jan Beulich
---
v2: Avoid commit message to continue from
: prefer xenbus_scanf() over xenbus_gather()
3: xen-blkfront: prefer xenbus_scanf() over xenbus_gather()
4: xen-netback: prefer xenbus_scanf() over xenbus_gather()
Signed-off-by: Jan Beulich
---
v2: Avoid commit messages to continue from subjects. Group into a series.
ff-by: Jan Beulich
---
drivers/xen/xen-acpi-processor.c | 35 +++
1 file changed, 3 insertions(+), 32 deletions(-)
--- 4.7-rc6/drivers/xen/xen-acpi-processor.c
+++ 4.7-rc6-xen-acpi-processor-prereqs/drivers/xen/xen-acpi-processor.c
@@ -423,36 +423,7 @@ u
>>> On 07.07.16 at 17:37, wrote:
> On Thu, Jul 07, 2016 at 10:52:18AM +0100, Andrew Cooper wrote:
>> 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
>>> 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:
>>> 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_ST
>>> 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 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
>>> 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 port
>>> 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 ++-
... as being the simpler variant.
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/pci_stub.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.7-rc6-prefer-xenbus_write.orig/drivers/xen/xen-pciback/pci_stub.c
+++ 4.7-rc6-prefer-xenbus_write/drivers/xen/xen-pciback
... 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-blkfront.c
+++ 4.7-rc6-prefer-xenbus_write/drivers/block/xen-blkfront.c
... 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
---
drivers/xen/xenbus/xenbus_client.c |6 +++---
1 file changed, 3 insertions
... as being the simpler variant.
Signed-off-by: Jan Beulich
---
drivers/block/xen-blkback/xenbus.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- 4.7-rc6-prefer-xenbus_write.orig/drivers/block/xen-blkback/xenbus.c
+++ 4.7-rc6-prefer-xenbus_write/drivers/block/xen-blkback
... 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
---
drivers/block/xen-blkfront.c | 43 +++
1
... 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
---
drivers/block/xen-blkback/xenbus.c | 13 ++---
1 file changed, 6
... as being the simpler variant.
Signed-off-by: Jan Beulich
---
drivers/video/fbdev/xen-fbfront.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- 4.7-rc6-prefer-xenbus_write.orig/drivers/video/fbdev/xen-fbfront.c
+++ 4.7-rc6-prefer-xenbus_write/drivers/video/fbdev/xen
Only a positive return value indicates success.
Signed-off-by: Jan Beulich
---
drivers/xen/manage.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.7-rc6-xenbus_scanf.orig/drivers/xen/manage.c
+++ 4.7-rc6-xenbus_scanf/drivers/xen/manage.c
@@ -275,7 +275,7 @@ static void
Set backend state to unknown when unsuccessful.
Signed-off-by: Jan Beulich
---
drivers/xen/xenbus/xenbus_probe_frontend.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- 4.7-rc6-xenbus_scanf.orig/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ 4.7-rc6-xenbus_scanf/drivers/xen
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/drivers/block/xen-blkfront.c
+++ 4.7-rc6-xen/drivers/block/xen-blkfront.c
The functions such get passed to have been taking pointers to const
since at least 2.6.16.
Signed-off-by: Jan Beulich
---
drivers/block/xen-blkback/xenbus.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.7-rc6-xen.orig/drivers/block/xen-blkback/xenbus.c
+++ 4.7-rc6-xen/drivers
... over list_for_each_safe() when list modification if accompanied by
breaking out of the loop.
Signed-off-by: Jan Beulich
---
drivers/xen/xenbus/xenbus_dev_frontend.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 4.7-rc6-xen.orig/drivers/xen/xenbus/xenbus_dev_frontend.c
Commit 9d092603cc ("xen-blkback: do not leak mode property") left one
path unfixed; correct this.
Signed-off-by: Jan Beulich
---
drivers/block/xen-blkback/xenbus.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- 4.7-rc6-xen.orig/drivers/block/xen-blkback/xenbus.c
+
Many of these operations can take arbitrarily long, which can become a
problem irrespective of them being exposed to privileged users only.
Signed-off-by: Jan Beulich
---
drivers/xen/privcmd.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
--- 4.7-rc6-xen.orig
This already gets done in HYPERVISOR_mca().
Signed-off-by: Jan Beulich
---
drivers/xen/mcelog.c |2 --
1 file changed, 2 deletions(-)
--- 4.7-rc6-xen.orig/drivers/xen/mcelog.c
+++ 4.7-rc6-xen/drivers/xen/mcelog.c
@@ -288,7 +288,6 @@ static int mc_queue_handle(uint32_t flag
int ret
There's no reason why this would need to be limited to x86-64.
Signed-off-by: Jan Beulich
---
drivers/xen/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.7-rc6-xen.orig/drivers/xen/Kconfig
+++ 4.7-rc6-xen/drivers/xen/Kconfig
@@ -264,7 +264,7 @@ config XEN_ACPI_PROC
No need to retain a local copy of the full request message, only the
type is really needed.
Signed-off-by: Jan Beulich
---
drivers/xen/xenbus/xenbus_xs.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- 4.7-rc6-xen.orig/drivers/xen/xenbus/xenbus_xs.c
+++ 4.7-rc6-xen/drivers
ce I can't identify whether a more complex
change might be needed here).
Signed-off-by: Jan Beulich
Cc: Konrad Rzeszutek Wilk
---
drivers/xen/xenbus/xenbus_xs.c |3 ---
1 file changed, 3 deletions(-)
--- 4.7-rc6-xen.orig/drivers/xen/xenbus/xenbus_xs.c
+++ 4.7-rc6-xen/drivers/xen/xen
1: don't bail early from xenbus_dev_request_and_reply()
2: simplify xenbus_dev_request_and_reply()
Signed-off-by: Jan Beulich
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.
Signed-off-by: Jan Beulich
---
drivers/
req_start is simply an alias of the "offset" function parameter, and
req_end is being used just once in each function. (And both variables
were loop invariant anyway, so should at least have got initialized
outside the loop.)
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/co
There's no point calling xen_pcibk_config_read() here - all it'll do is
return whatever conf_space_read() returns for the field which was found
here (and which would be found there again). Also there's no point
clearing tmp_val before the call.
Signed-off-by: Jan Beulich
---
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/conf_space_header.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_header.c
+++ 4.7-rc6-xen-pciback/drivers/xen/xen-pciback/conf_space_header.c
@@ -211,8 +211,8
Other than for raw BAR values, flags are properly separated in the
internal representation.
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/conf_space_header.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/conf_space_header.c | 33 +++-
1 file changed, 13 insertions(+), 20 deletions(-)
--- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_header.c
+++ 4.7-rc6-xen-pciback/drivers/xen/xen-pciback
It is now identical to bar_init().
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/conf_space_header.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
--- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_header.c
+++ 4.7-rc6-xen-pciback/drivers/xen/xen
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/conf_space_header.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- 4.7-rc6-xen-pciback.orig/drivers/xen/xen-pciback/conf_space_header.c
+++ 4.7-rc6-xen-pciback/drivers/xen/xen-pciback/conf_space_header.c
@@ -210,8
single caller
4: simplify determination of 64-bit memory resource
5: use const and unsigned in bar_init()
6: short-circuit read path used for merging write values
7: drop superfluous variables
Signed-off-by: Jan Beulich
>>> 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 plea
>>> On 01.07.16 at 14:06, wrote:
> "Jan Beulich" writes:
>
>>>>> 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 look at
>>
>>> 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 look at
>> the attached patch. If we can guarantee long term that ACPI id always
>> equals to Xen's idea of vCPU id this is probably the easiest way.
>>
>>> On 29.06.16 at 17:00, wrote:
> --- a/arch/x86/xen/enlighten.c
> +++ b/arch/x86/xen/enlighten.c
> @@ -591,7 +591,7 @@ static void xen_load_gdt(const struct desc_ptr *dtr)
> {
> unsigned long va = dtr->address;
> unsigned int size = dtr->size + 1;
> - unsigned pages = (size + PA
>>> On 24.06.16 at 17:01, wrote:
> On 07/06/16 07:31, Jan Beulich wrote:
>> - drop unused function parameter of read_dev_bar()
>> - drop rom_init() (now identical to bar_init())
>> - fold read_dev_bar() into its now single caller
>> - simplify determinatio
n-address bits, not just the ROM
Enable one.
Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
---
v3: Use ~0U in rom_write(), to account for PCI_ROM_ADDRESS_MASK being
of unsigned long type (relevant on 64-bit). (Note: Patch 2 is
unchanged, and hence not being re-sent. I hope that
>>> On 07.06.16 at 16:06, wrote:
> On 06/07/2016 02:30 AM, Jan Beulich wrote:
>> Reads following writes with all address bits set to 1 should return all
>> changeable address bits as one, not the BAR size (nor, as was the case
>> for the upper half of 64-bit BARs,
- drop unused function parameter of read_dev_bar()
- drop rom_init() (now identical to bar_init())
- fold read_dev_bar() into its now single caller
- simplify determination of 64-bit memory resource
- use const and unsigned
Signed-off-by: Jan Beulich
---
v2: fold in 3rd patch and drop
n-address bits, not just the ROM
Enable one.
Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
---
drivers/xen/xen-pciback/conf_space_header.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
--- 4.7-rc2-xen-pciback-BAR.orig/drivers/xen/xen-pciback/conf_space_header
1: return proper values during BAR sizing
2: clean up {bar,rom}_init()
Signed-off-by: Jan Beulich
---
v2: Fold (and extend) patches 2 and 3. Patch 1 is unchanged.
>>> On 06.06.16 at 15:09, wrote:
> On 06/06/2016 04:47 AM, Jan Beulich wrote:
>> It's identical to bar_init() now.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> I'm sorry for this 3/2 - I only now noticed that this additional
>> simplifica
>>> On 06.06.16 at 15:03, wrote:
> On 06/06/2016 04:11 AM, Jan Beulich wrote:
>> @@ -225,38 +225,42 @@ static inline void read_dev_bar(struct p
>> (PCI_BASE_ADDRESS_SPACE_MEMORY |
>>
It's identical to bar_init() now.
Signed-off-by: Jan Beulich
---
I'm sorry for this 3/2 - I only now noticed that this additional
simplification is now possible.
---
drivers/xen/xen-pciback/conf_space_header.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
-
- drop unused function parameter
- simplify determination of 64-bit memory resource
- use const and unsigned
Signed-off-by: Jan Beulich
---
drivers/xen/xen-pciback/conf_space_header.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
--- 4.7-rc2-xen-pciback-BAR.orig
201 - 300 of 1372 matches
Mail list logo
