>>> 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 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
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
: 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.
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
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
>>> 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
>>> 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 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 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
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
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
>>> 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 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
>>> 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 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 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 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 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 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 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
>>
>>> 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 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 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 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 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-
>>> 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 -
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
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
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_
>>> 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 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);
>
> -
>>> 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 23.03.17 at 13:52, wrote:
> Connecting to the backend isn't working reliably in xen-fbfront: in
> case XenbusStateInitWait of the backend has been missed the backend
> transition to XenbusStateConnected will trigger the connected state
> only without doing the actions required when the back
>>> On 23.03.17 at 14:56, wrote:
> On 23/03/17 14:37, Jan Beulich wrote:
>>>>> On 23.03.17 at 13:52, wrote:
>>> Connecting to the backend isn't working reliably in xen-fbfront: in
>>> case XenbusStateInitWait of the backend has been missed the b
>>> On 09.02.17 at 15:17, wrote:
> The code goes so far as to set the default return code to -ENOSYS but
> then overrides this to -EINVAL in the switch() statement's default
> case.
If you already change this, isn't -ENOTTY the traditional way of
indicating unsupported ioctls?
Jan
>>> On 09.02.17 at 15:17, wrote:
> @@ -666,6 +680,20 @@ static long privcmd_ioctl_dm_op(void __user *udata)
> return rc;
> }
>
> +static long privcmd_ioctl_restrict(struct file *file, void __user *udata)
> +{
> + struct privcmd_data *data = file->private_data;
> + domid_t dom;
> +
>>> On 09.02.17 at 16:56, wrote:
> On 09/02/17 15:50, Boris Ostrovsky wrote:
>>
>>
>> On 02/09/2017 09:27 AM, Paul Durrant wrote:
-Original Message-
From: Paul Durrant [mailto:paul.durr...@citrix.com]
Sent: 09 February 2017 14:18
To: xen-de...@lists.xenproject.org; linu
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
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
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
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)
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.
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
- 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
>>> 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,
>>> 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
>>> 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 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:
>> >
1: return proper values during BAR sizing
2: clean up read_dev_bar()
Signed-off-by: Jan Beulich
Side note: I had always assumed Konrad is the maintainer of pciback,
but according to ./MAINTAINERS he isn't: drivers/pci/*xen*, while
using wild cards, doesn't match drivers/xen/xen-pci
n-address bits, not just the ROM
Enable one.
Signed-off-by: Jan Beulich
---
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.c
+++ 4.7-rc2-xen-pciback-B
- 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
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(-)
-
>>> 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 |
>>
>>> 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 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
>>> 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 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 21.03.16 at 13:24, wrote:
> @@ -758,9 +759,14 @@ struct smp_sync_call_struct {
> static void smp_call_sync_callback(struct work_struct *work)
> {
> struct smp_sync_call_struct *sscs;
> + unsigned int cpu = smp_processor_id();
So this obtains the vCPU number, yet ...
> ss
- for example they have no
> legacy interrupts, and also any writes to PCI_COMMAND_MEMORY
> are silently ignored (by the hardware).
>
> CC: sta...@vger.kernel.org
> Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Jan Beulich
albeit ...
> --- a/drivers/xen/xen-pciback/pciba
nel.org
> Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Jan Beulich
but I'd prefer to see ...
> --- a/drivers/xen/xen-pciback/pciback_ops.c
> +++ b/drivers/xen/xen-pciback/pciback_ops.c
> @@ -335,7 +335,9 @@ void xen_pcibk_do_op(struct work_struct *data)
> struct
>>> On 21.08.15 at 21:12, wrote:
> SAVE_ALL and RESTORE_ALL macros for !CONFIG_X86_64 were introduced in the
> 1a338ac32 commit (sched, x86: Optimize the preempt_schedule() call) and
> were used in the ___preempt_schedule and ___preempt_schedule_context from
> the arch/x86/kernel/preempt.S. But t
>>> Borislav Petkov 12/22/15 7:14 PM >>>
>On Tue, Dec 22, 2015 at 10:20:36AM -0700, Jan Beulich wrote:
>> As said - 4.3.4 (I only now realize that this could also have been a
>> kernel version).
>
>Just fetched stable from
>git://git.kernel.org/pu
>>> Borislav Petkov 12/23/15 11:10 AM >>>
>On Wed, Dec 23, 2015 at 03:06:08AM -0700, Jan Beulich wrote:
>> Sigh - this was in reply to your gcc version question. Right after having
>> sent
>> the most recent reply I realized that there's no Li
Commit 599bad38cf added BUS_NOTIFY_REMOVED_DEVICE in order to allow
avoiding removal of IOMMU mappings before the driver actually got
unbound from the device. Naturally we should be using this too.
Signed-off-by: Jan Beulich
---
drivers/xen/pci.c |2 +-
1 file changed, 1 insertion(+), 1
>>> On 01.02.16 at 13:01, wrote:
> On 01/02/16 11:58, Jan Beulich wrote:
>> Commit 599bad38cf added BUS_NOTIFY_REMOVED_DEVICE in order to allow
>> avoiding removal of IOMMU mappings before the driver actually got
>> unbound from the device. Naturally we should b
>>> On 01.02.16 at 14:03, wrote:
> On 01/02/16 12:16, Jan Beulich wrote:
>>>>> On 01.02.16 at 13:01, wrote:
>>> On 01/02/16 11:58, Jan Beulich wrote:
>>>> Commit 599bad38cf added BUS_NOTIFY_REMOVED_DEVICE in order to allow
>>>> avoid
>>> On 28.01.16 at 09:42, wrote:
> Could we try a v3?
Okay, I withdraw the patch: Upon further consideration it is note
really clear what the intended behavior of set_memory_*() on
address ranges with mapping holes is supposed to be. The original
issue was with set_memory_nx() (called from mark_r
This doesn't just eliminate needless redundancy (plus avoid a possible
disconnect if one string instance gets changed without the other(s)),
but also eliminates a warning some gcc versions emit ("array access
beyond array bounds", observed with 4.3.4) in the 32-bit case.
Sig
This was meant to print base address and entry count; make it do so
again.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/process_64.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 4.4-rc6/arch/x86/kernel/process_64.c
+++ 4.4-rc6-x86-LDT-message/arch/x86/kernel/process_64.c
>>> On 22.12.15 at 18:07, wrote:
> On Tue, Dec 22, 2015 at 08:40:43AM -0700, Jan Beulich wrote:
>> This doesn't just eliminate needless redundancy
>> (plus avoid a possible disconnect if one string instance gets changed
>> without the other(s)),
>
> T
>>> On 27.01.16 at 11:05, wrote:
> On Mon, 25 Jan 2016, Jan Beulich wrote:
>
> Sorry, that changelog does not make any sense.
>
>> Since successful return from __cpa_process_fault() makes
>> __change_page_attr() exit early (and successfully), its caller needs to
>>> On 27.01.16 at 11:53, wrote:
> Documentation/SubmittingPatches:: 2) Describe your changes.
So what is it that you think I've done?
Anyway, I'll make a second try, and if that's still not understandable
likely give up (and retain the bug fix in my own trees) unless given
more clear guidance o
ult() to get called meant early termination of the
processing without having processed the entire range, yet still
reporting success.
Signed-off-by: Jan Beulich
---
v2: Completely re-written description.
---
arch/x86/mm/pageattr.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
---
ot;unsigned long" is inefficient for 64-bit
kernels when dealing with cachability flags alone - "unsigned int" is
sufficient here and allows for slightly smaller code to be generated.
Fixes: 281d4078be ("x86: Make page cache mode a real type")
Signed-off-by: Jan Beulich
k_clr" equals _PAGE_NX, as e.g. passed from set_memory_{,n}x().
Signed-off-by: Jan Beulich
---
arch/x86/mm/pageattr.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- 4.5-rc1/arch/x86/mm/pageattr.c
+++ 4.5-rc1-x86-cpa-non-primary/arch/x86/mm/pageattr.c
@@ -1122,8 +112
ke page cache mode a real type")
Signed-off-by: Jan Beulich
Cc: Juergen Gross
---
v2: Remove code enhancement part, as requested by tglx.
---
arch/x86/include/asm/pgtable_types.h |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
--- 4.5-rc1/arch/x86/include/asm/pgtable_typ
ssions it is necessary to observe the full
> hierarchy of the page tree.
>
> Introduce a new callback for ptdump which is called for every entry and
> can therefore update the prot_levels array correctly. note_page() can
> then simply access the appropriate element in the array.
&g
called from init_mem_mapping()) where fixmap
mappings would get established without NX set. For a 32-bit kernel
running in PV mode under Xen this meant a W+X mapping (and associated
warning) for its shared info page mapping established in
xen_pv_init_platform().
Signed-off-by: Jan Beulich
--- a
On 25.09.2020 15:45, boris.ostrov...@oracle.com wrote:
> On 9/25/20 6:11 AM, Juergen Gross wrote:
>> @@ -1296,6 +1296,14 @@ asmlinkage __visible void __init
>> xen_start_kernel(void)
>>
>> xen_smp_init();
>>
>> +#ifdef CONFIG_ACPI
>> +/*
>> + * Disable selecting "Firmware First mo
On 14.10.2020 19:53, Jason Andryuk wrote:
> @@ -76,7 +80,9 @@ config XEN_DEBUG_FS
> Enabling this option may incur a significant performance overhead.
>
> config XEN_PVH
> - bool "Support for running as a Xen PVH guest"
> + bool "Xen PVH guest support"
Tangential question: Is "g
On 15.10.2020 16:59, Jason Andryuk wrote:
> On Thu, Oct 15, 2020 at 4:10 AM Jan Beulich wrote:
>>
>> On 14.10.2020 19:53, Jason Andryuk wrote:
>>> @@ -76,7 +80,9 @@ config XEN_DEBUG_FS
>>> Enabling this option may incur a significant performance
On 22.10.2020 09:42, Juergen Gross wrote:
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -2050,7 +2050,7 @@ void xen_setup_callback_vector(void) {}
> static inline void xen_alloc_callback_vector(void) {}
> #endif
>
> -static bool fifo_events = true;
> +bo
On 22.10.2020 09:42, Juergen Gross wrote:
> --- a/drivers/xen/events/events_fifo.c
> +++ b/drivers/xen/events/events_fifo.c
> @@ -236,6 +236,9 @@ static bool clear_masked_cond(volatile event_word_t *word)
>
> w = *word;
>
> + if (!(w & (1 << EVTCHN_FIFO_MASKED)))
> + retur
nts
> xen/events: unmask a fifo event channel only if it was masked
> Documentation: add xen.fifo_events kernel parameter description
With the two remarks to individual patches suitably taken care of
one way or another
Reviewed-by: Jan Beulich
Jan
On 22.10.2020 11:49, Juergen Gross wrote:
> @@ -2080,10 +2080,12 @@ void __init xen_init_IRQ(void)
> int ret = -EINVAL;
> evtchn_port_t evtchn;
>
> - if (fifo_events)
> + if (xen_fifo_events)
> ret = xen_evtchn_fifo_init();
> - if (ret < 0)
> + if (ret <
On 22.10.2020 15:09, Jürgen Groß wrote:
> On 22.10.20 12:35, Jan Beulich wrote:
>> On 22.10.2020 11:49, Juergen Gross wrote:
>>> @@ -2080,10 +2080,12 @@ void __init xen_init_IRQ(void)
>>> int ret = -EINVAL;
>>> evtchn_port_t evtchn;
>&g
>>> On 12.06.19 at 12:12, wrote:
> When running as a Xen guest selecting "nosmt" either via command line
> or implicitly via default settings makes no sense, as the guest has no
> clue about the real system topology it is running on. With Xen it is
> the hypervisor's job to ensure the proper bug m
Steven,
in the description of this change you say:
"The effective permissions are passed down the chain using new fields in
struct pg_state."
I don't see how this works, and I suppose this part of the change is
(part of) the reason why a W+X warning has magically disappeared in
5.6.x (compared
On 12.05.2020 15:02, Steven Price wrote:
> On 12/05/2020 10:39, Jan Beulich wrote:
>> Additionally I'd like to note that note_page()'s "unsigned long val"
>> parameter isn't wide enough for 32-bit PAE PTEs, and hence the NX
>> flag will always be seen
>>> On 28.03.17 at 03:57, wrote:
> I think there is indeed a disconnect between target memory (provided by
> the toolstack) and current memory (i.e actual pages available to the guest).
>
> For example
>
> [0.00] BIOS-e820: [mem 0x0009e000-0x0009]
> reserved
> [
>>> On 28.03.17 at 16:27, wrote:
> Which leaves hvmloader's special pages (and possibly memory under
> 0xA which may get reserved). Can we pass this info to guests via
> xenstore?
I'm perhaps the wrong one to ask regarding xenstore, but for
in-guest communication this seems an at least strang
>>> On 27.04.17 at 02:55, wrote:
> The point of CR3 loading here, I believe, is to make sure the hypervisor
> knows that the (v)CPU is no longer using the the mm's cr3 (we are
> loading swapper_pgdir here).
Correct, or else there would still be a non-zero refcount for the
page tables hanging of
>>> On 30.03.17 at 16:18, wrote:
> @@ -2903,3 +2906,13 @@ int xen_unmap_domain_gfn_range(struct vm_area_struct
> *vma,
> return -EINVAL;
> }
> EXPORT_SYMBOL_GPL(xen_unmap_domain_gfn_range);
> +
> +#ifdef CONFIG_KEXEC_CORE
> +phys_addr_t paddr_vmcoreinfo_note(void)
> +{
> + if (xen_pv_
>>> On 05.07.17 at 10:08, wrote:
> Without the patch, blkif_release and xlvbd_release_gendisk are never
> called, and no call to blk_unregister_queue is made.
But isn't that what needs to be fixed then? The device should be
removed once its last user goes away (which would be at the time
the umou
>>> On 05.07.17 at 14:37, wrote:
> On Wed, Jul 05, 2017 at 02:17:24AM -0600, Jan Beulich wrote :
>> >>> On 05.07.17 at 10:08, wrote:
>> > Without the patch, blkif_release and xlvbd_release_gendisk are never
>> > called, and no call to blk_unregis
>>> On 05.07.17 at 17:38, wrote:
> @@ -94,22 +103,15 @@ static struct notifier_block xenstore_notifier = {
> .notifier_call = balloon_init_watcher,
> };
>
> -static int __init balloon_init(void)
> +void __init xen_balloon_init(void)
> {
> - if (!xen_domain())
> - return -
n L1, but _PAGE_NX is
set in L2.
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
---
v2: Re-base onto tip tree. Add Xen related paragraph to description.
---
arch/x86/mm/dump_pagetables.c | 92 ++
1 file changed, 57 insertions(+), 35 deleti
1101 - 1200 of 1374 matches
Mail list logo
