On 29/04/15 22:10, Boris Ostrovsky wrote:
After a resume the hypervisor/tools may change xenbus event
channel number. We should re-query it.
Reviewed-by: David Vrabel david.vra...@citrix.com
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On 29/04/15 22:10, Boris Ostrovsky wrote:
When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level events it
is possible for the interrupt to be claimed by wrong VCPU since
cpu_evtchn_mask bits may be stale. This can happen even
On 29/04/15 17:54, Boris Ostrovsky wrote:
> On 04/29/2015 12:32 PM, David Vrabel wrote:
>> On 28/04/15 19:29, Boris Ostrovsky wrote:
>>> On 04/28/2015 12:28 PM, David Vrabel wrote:
>>>>
>>>> From the commit log the evtchn_2l_resume() fucntion t
On 28/04/15 19:29, Boris Ostrovsky wrote:
> On 04/28/2015 12:28 PM, David Vrabel wrote:
>> On 28/04/15 16:52, Boris Ostrovsky wrote:
>>> When a guest is resumed, the hypervisor may change event channel
>>> assignments. If this happens and the guest uses 2-leve
On 28/04/15 23:46, Boris Ostrovsky wrote:
> Commit 77e32c89a711 ("clockevents: Manage device's state separately for
> the core") decouples clockevent device's modes from states. With this
> change when a Xen guest tries to resume, it won't be calling its
> set_mode op which needs to be done on
On 28/04/15 23:46, Boris Ostrovsky wrote:
Commit 77e32c89a711 (clockevents: Manage device's state separately for
the core) decouples clockevent device's modes from states. With this
change when a Xen guest tries to resume, it won't be calling its
set_mode op which needs to be done on each VCPU
On 29/04/15 17:54, Boris Ostrovsky wrote:
On 04/29/2015 12:32 PM, David Vrabel wrote:
On 28/04/15 19:29, Boris Ostrovsky wrote:
On 04/28/2015 12:28 PM, David Vrabel wrote:
From the commit log the evtchn_2l_resume() fucntion that's added
sounds
like it fixes the problem on its own
On 28/04/15 19:29, Boris Ostrovsky wrote:
On 04/28/2015 12:28 PM, David Vrabel wrote:
On 28/04/15 16:52, Boris Ostrovsky wrote:
When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level events it
is possible for the interrupt
On 28/04/15 16:52, Boris Ostrovsky wrote:
> After a resume the hypervisor/tools may change xenbus event
> channel number. We should re-query it.
[...]
> @@ -793,6 +818,9 @@ static int __init xenbus_init(void)
> goto out_error;
> }
>
> + if (!xen_initial_domain())
> +
On 28/04/15 16:52, Boris Ostrovsky wrote:
> When a guest is resumed, the hypervisor may change event channel
> assignments. If this happens and the guest uses 2-level events it
> is possible for the interrupt to be claimed by wrong VCPU since
> cpu_evtchn_mask bits may be stale. This can happen
On 28/04/15 16:52, Boris Ostrovsky wrote:
> .. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to
> 'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu().
Reviewed-by: David Vrabel
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
On 28/04/15 16:52, Boris Ostrovsky wrote:
> After a resume the hypervisor/tools may change console event
> channel number. We should re-query it.
Reviewed-by: David Vrabel
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
On 28/04/15 16:52, Boris Ostrovsky wrote:
.. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to
'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu().
Reviewed-by: David Vrabel david.vra...@citrix.com
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On 28/04/15 16:52, Boris Ostrovsky wrote:
After a resume the hypervisor/tools may change console event
channel number. We should re-query it.
Reviewed-by: David Vrabel david.vra...@citrix.com
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On 28/04/15 16:52, Boris Ostrovsky wrote:
When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level events it
is possible for the interrupt to be claimed by wrong VCPU since
cpu_evtchn_mask bits may be stale. This can happen even
On 28/04/15 16:52, Boris Ostrovsky wrote:
After a resume the hypervisor/tools may change xenbus event
channel number. We should re-query it.
[...]
@@ -793,6 +818,9 @@ static int __init xenbus_init(void)
goto out_error;
}
+ if (!xen_initial_domain())
+
On 08/04/15 19:53, Boris Ostrovsky wrote:
> Commit 77e32c89a711 ("clockevents: Manage device's state separately for
> the core") decouples clockevent device's modes from states. With this
> change when a Xen guest tries to resume, it won't be calling its
> set_mode op which needs to be done on
On 08/04/15 19:53, Boris Ostrovsky wrote:
Commit 77e32c89a711 (clockevents: Manage device's state separately for
the core) decouples clockevent device's modes from states. With this
change when a Xen guest tries to resume, it won't be calling its
set_mode op which needs to be done on each VCPU
On 23/04/15 10:47, Stefano Stabellini wrote:
> Make sure that xen_swiotlb_init allocates buffers that are DMA capable
> when at least one memblock is available below 4G. Otherwise we assume
> that all devices on the SoC can cope with >4G addresses.
This commit message must explain why the PFNs
On 23/04/15 10:47, Stefano Stabellini wrote:
Make sure that xen_swiotlb_init allocates buffers that are DMA capable
when at least one memblock is available below 4G. Otherwise we assume
that all devices on the SoC can cope with 4G addresses.
This commit message must explain why the PFNs (IPAs)
uests on Broadwell hardware. The BUG_ON() is consistent for an individual
> build, but not consistent for all builds. It has also been a sitting timebomb
> since SMAP support was introduced.
>
> Use native_save_fl() instead, which will obtain an accurate view of the AC
>
On 20/04/15 12:07, Chen Baozi wrote:
> On Mon, Apr 20, 2015 at 11:53:47AM +0100, David Vrabel wrote:
>> On 20/04/15 11:48, Chen Baozi wrote:
>>> Make sure that xen_swiotlb_init allocates buffers that is DMA capable.
>>>
>>> Signed-off-by: Chen Baozi
>&g
On 20/04/15 12:07, Chen Baozi wrote:
On Mon, Apr 20, 2015 at 11:53:47AM +0100, David Vrabel wrote:
On 20/04/15 11:48, Chen Baozi wrote:
Make sure that xen_swiotlb_init allocates buffers that is DMA capable.
Signed-off-by: Chen Baozi baoz...@gmail.com
---
drivers/xen/swiotlb-xen.c | 3
. The BUG_ON() is consistent for an individual
build, but not consistent for all builds. It has also been a sitting timebomb
since SMAP support was introduced.
Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.
Reviewed-by: David Vrabel david.vra...@citrix.com
David
changed, 1246 insertions(+), 694 deletions(-)
Dan Carpenter (1):
xen/mce: fix up xen_late_init_mcelog() error handling
David Vrabel (2):
xen: unify foreign GFN map/unmap for auto-xlated physmap guests
xen/privcmd: improve performance of MMAPBATCH_V2
Jan Beulich (1):
xen-pciback:
(+), 694 deletions(-)
Dan Carpenter (1):
xen/mce: fix up xen_late_init_mcelog() error handling
David Vrabel (2):
xen: unify foreign GFN map/unmap for auto-xlated physmap guests
xen/privcmd: improve performance of MMAPBATCH_V2
Jan Beulich (1):
xen-pciback: also support
On 13/04/15 09:36, Bob Liu wrote:
> Hi Stephen,
>
> On 04/13/2015 04:09 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the xen-tip tree, today's linux-next build (x86_64
>> allmodconfig)
>> failed like this:
>>
>> drivers/char/tpm/xen-tpmfront.c: In function 'setup_ring':
>>
On 13/04/15 09:36, Bob Liu wrote:
Hi Stephen,
On 04/13/2015 04:09 PM, Stephen Rothwell wrote:
Hi all,
After merging the xen-tip tree, today's linux-next build (x86_64
allmodconfig)
failed like this:
drivers/char/tpm/xen-tpmfront.c: In function 'setup_ring':
case such an area is found reserve it at once as this will be
> required to be done in any case.
Reviewed-by: David Vrabel
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at h
On 09/04/2015 07:55, Juergen Gross wrote:
> Check whether the initrd is placed at a location which is conflicting
> with the target E820 map. If this is the case relocate it to a new
> area unused up to now and compliant to the E820 map.
Reviewed-by: David Vrabel
David
--
To unsubsc
On 09/04/2015 07:55, Juergen Gross wrote:
> Checks whether the pre-allocated memory of the loaded kernel is in
> conflict with the target memory map. If this is the case, just panic
> instead of run into problems later, as there is nothing we can do
> to repair this situation.
Review
On 09/04/2015 07:55, Juergen Gross wrote:
> Check whether the page tables built by the domain builder are at
> memory addresses which are in conflict with the target memory map.
> If this is the case just panic instead of running into problems
> later.
>
> Signed-off-by: Juergen Gross
> ---
>
-573,6 +573,29 @@ static unsigned long __init
> xen_count_remap_pages(unsigned long max_pfn)
> return extra;
> }
>
> +bool __init xen_chk_e820_reserved(phys_addr_t start, phys_addr_t size)
Can you rename this to xen_is_e280_reserved().
Otherwise,
Reviewed-by: David Vr
On 09/04/15 07:55, Juergen Gross wrote:
> In case the Xen tools indicate they don't need the p2m 3 level tree
> as they support the virtual mapped linear p2m list, just omit building
> the tree.
Reviewed-by: David Vrabel
David
--
To unsubscribe from this list: send the line "uns
count which is changed prior
> to and after each mapping change of the p2m list. Reading the
> generation count the Xen tools can detect changes of the mappings
> and re-read the p2m list eventually.
Reviewed-by: David Vrabel
David
--
To unsubscribe from this list: send the line &quo
On 09/04/15 07:55, Juergen Gross wrote:
> Use the newest headers from the xen tree to get some new structure
> layouts.
Reviewed-by: David Vrabel
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.or
On 09/04/15 07:55, Juergen Gross wrote:
In case the Xen tools indicate they don't need the p2m 3 level tree
as they support the virtual mapped linear p2m list, just omit building
the tree.
Reviewed-by: David Vrabel david.vra...@citrix.com
David
--
To unsubscribe from this list: send the line
On 09/04/2015 07:55, Juergen Gross wrote:
Checks whether the pre-allocated memory of the loaded kernel is in
conflict with the target memory map. If this is the case, just panic
instead of run into problems later, as there is nothing we can do
to repair this situation.
Reviewed-by: David
xen_count_remap_pages(unsigned long max_pfn)
return extra;
}
+bool __init xen_chk_e820_reserved(phys_addr_t start, phys_addr_t size)
Can you rename this to xen_is_e280_reserved().
Otherwise,
Reviewed-by: David Vrabel david.vra...@citrix.com
David
--
To unsubscribe from this list
is changed prior
to and after each mapping change of the p2m list. Reading the
generation count the Xen tools can detect changes of the mappings
and re-read the p2m list eventually.
Reviewed-by: David Vrabel david.vra...@citrix.com
David
--
To unsubscribe from this list: send the line unsubscribe
reserve it at once as this will be
required to be done in any case.
Reviewed-by: David Vrabel david.vra...@citrix.com
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On 09/04/2015 07:55, Juergen Gross wrote:
Check whether the page tables built by the domain builder are at
memory addresses which are in conflict with the target memory map.
If this is the case just panic instead of running into problems
later.
Signed-off-by: Juergen Gross jgr...@suse.com
On 09/04/15 07:55, Juergen Gross wrote:
Use the newest headers from the xen tree to get some new structure
layouts.
Reviewed-by: David Vrabel david.vra...@citrix.com
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
On 09/04/2015 07:55, Juergen Gross wrote:
Check whether the initrd is placed at a location which is conflicting
with the target E820 map. If this is the case relocate it to a new
area unused up to now and compliant to the E820 map.
Reviewed-by: David Vrabel david.vra...@citrix.com
David
On 07/04/15 03:55, Waiman Long wrote:
> This patch adds the necessary Xen specific code to allow Xen to
> support the CPU halting and kicking operations needed by the queue
> spinlock PV code.
This basically looks the same as the version I wrote, except I think you
broke it.
> +static void
On 07/04/15 03:55, Waiman Long wrote:
This patch adds the necessary Xen specific code to allow Xen to
support the CPU halting and kicking operations needed by the queue
spinlock PV code.
This basically looks the same as the version I wrote, except I think you
broke it.
+static void
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
stable/for-linus-4.0-rc6-tag
xen: regression fixes for 4.0-rc6
- - Fix two regressions in the balloon driver's use of memory hotplug
when used
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
stable/for-linus-4.0-rc6-tag
xen: regression fixes for 4.0-rc6
- - Fix two regressions in the balloon driver's use of memory hotplug
when used
1e ("x86/asm/entry: Replace this_cpu_sp0() with
> current_top_of_stack()
> to x86_32") to 32-bit Xen PV guests.
Reviewed-by: David Vrabel
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@
On 26/03/15 12:16, Bob Liu wrote:
> There are several place using gnttab async unmap and wait for
> completion, so move the common code to a function
> gnttab_unmap_refs_async_wait_completion().
>
[...]
> +
> +int gnttab_unmap_refs_async_wait_completion(struct gntab_unmap_queue_data*
> item)
On 30/03/15 01:03, Bob Liu wrote:
>
> On 03/28/2015 08:44 AM, Konrad Rzeszutek Wilk wrote:
>> On Thu, Mar 26, 2015 at 04:32:45PM +0100, Roger Pau Monné wrote:
>>> El 26/03/15 a les 13.16, Bob Liu ha escrit:
There are several place using gnttab async unmap and wait for
completion, so
On 26/03/15 12:16, Bob Liu wrote:
There are several place using gnttab async unmap and wait for
completion, so move the common code to a function
gnttab_unmap_refs_async_wait_completion().
[...]
+
+int gnttab_unmap_refs_async_wait_completion(struct gntab_unmap_queue_data*
item)
This name
On 30/03/15 01:03, Bob Liu wrote:
On 03/28/2015 08:44 AM, Konrad Rzeszutek Wilk wrote:
On Thu, Mar 26, 2015 at 04:32:45PM +0100, Roger Pau Monné wrote:
El 26/03/15 a les 13.16, Bob Liu ha escrit:
There are several place using gnttab async unmap and wait for
completion, so move the common
: Replace this_cpu_sp0() with
current_top_of_stack()
to x86_32) to 32-bit Xen PV guests.
Reviewed-by: David Vrabel david.vra...@citrix.com
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On 20/03/15 12:55, Juergen Gross wrote:
> Fix some regressions introduced in 3.16 and 3.19.
Applied to stable/for-linus-4.0 and tagged for stable, thanks.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On 23/03/15 14:29, Juergen Gross wrote:
> On 03/23/2015 01:46 PM, David Vrabel wrote:
>> On 20/03/15 12:55, Juergen Gross wrote:
>>> Commit 054954eb051f35e74b75a566a96fe756015352c8 ("xen: switch to linear
>>> virtual mapped sparse p2m list") introduced a regre
On 20/03/15 12:55, Juergen Gross wrote:
> Commit 054954eb051f35e74b75a566a96fe756015352c8 ("xen: switch to linear
> virtual mapped sparse p2m list") introduced a regression regarding to
> memory hotplug for a pv-domain: as the virtual space for the p2m list
> is allocated for the to be expected
On 20/03/15 13:46, Daniel Kiper wrote:
> On Fri, Mar 20, 2015 at 01:55:39PM +0100, Juergen Gross wrote:
>> Commit 25b884a83d487fd62c3de7ac1ab5549979188482 ("x86/xen: set
>> regions above the end of RAM as 1:1") introduced a regression.
>>
>
> Should not we fill everything above "maxmem" with
>
s which were added via memory hotplug to
>> a pv domain, the pages must be "invalid" instead of "identity" in the
>> p2m list before they can be added.
>>
>> Suggested-by: David Vrabel
>> Signed-off-by: Juergen Gross
>> ---
>> drivers/xe
On 20/03/15 12:55, Juergen Gross wrote:
Commit 054954eb051f35e74b75a566a96fe756015352c8 (xen: switch to linear
virtual mapped sparse p2m list) introduced a regression regarding to
memory hotplug for a pv-domain: as the virtual space for the p2m list
is allocated for the to be expected memory
On 20/03/15 13:46, Daniel Kiper wrote:
On Fri, Mar 20, 2015 at 01:55:39PM +0100, Juergen Gross wrote:
Commit 25b884a83d487fd62c3de7ac1ab5549979188482 (x86/xen: set
regions above the end of RAM as 1:1) introduced a regression.
Should not we fill everything above maxmem with
, the pages must be invalid instead of identity in the
p2m list before they can be added.
Suggested-by: David Vrabel david.vra...@citrix.com
Signed-off-by: Juergen Gross jgr...@suse.com
---
drivers/xen/balloon.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers
On 23/03/15 14:29, Juergen Gross wrote:
On 03/23/2015 01:46 PM, David Vrabel wrote:
On 20/03/15 12:55, Juergen Gross wrote:
Commit 054954eb051f35e74b75a566a96fe756015352c8 (xen: switch to linear
virtual mapped sparse p2m list) introduced a regression regarding to
memory hotplug for a pv
On 20/03/15 12:55, Juergen Gross wrote:
Fix some regressions introduced in 3.16 and 3.19.
Applied to stable/for-linus-4.0 and tagged for stable, thanks.
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
be a way to disable QUEUE_SPINLOCKS when supported by
the arch, is this intentional? If so, the existing ticketlock code could go.
David
8<--
x86/xen: paravirt support for qspinlocks
Provide the wait and kick ops necessary for paravirt-aware queue
spinlocks.
Signed-o
On 19/03/15 17:19, Juergen Gross wrote:
> On 03/19/2015 05:18 PM, David Vrabel wrote:
>> On 19/03/15 14:31, Juergen Gross wrote:
>>> Commit 25b884a83d487fd62c3de7ac1ab5549979188482 ("x86/xen: set
>>> regions above the end of RAM as 1:1") introduced a regress
On 19/03/15 17:16, Juergen Gross wrote:
> On 03/19/2015 05:18 PM, David Vrabel wrote:
>> On 19/03/15 14:31, Juergen Gross wrote:
>>> Commit 054954eb051f35e74b75a566a96fe756015352c8 ("xen: switch to linear
>>> virtual mapped sparse p2m list") introduced a regre
On 19/03/15 14:31, Juergen Gross wrote:
> Commit 25b884a83d487fd62c3de7ac1ab5549979188482 ("x86/xen: set
> regions above the end of RAM as 1:1") introduced a regression.
>
> To be able to add memory pages which were added via memory hotplug to
> a pv domain, the pages must be "invalid" instead of
On 19/03/15 14:31, Juergen Gross wrote:
> Commit 054954eb051f35e74b75a566a96fe756015352c8 ("xen: switch to linear
> virtual mapped sparse p2m list") introduced a regression regarding to
> memory hotplug for a pv-domain: as the virtual space for the p2m list
> is allocated for the to be expected
On 19/03/15 17:19, Juergen Gross wrote:
On 03/19/2015 05:18 PM, David Vrabel wrote:
On 19/03/15 14:31, Juergen Gross wrote:
Commit 25b884a83d487fd62c3de7ac1ab5549979188482 (x86/xen: set
regions above the end of RAM as 1:1) introduced a regression.
To be able to add memory pages which were
On 19/03/15 17:16, Juergen Gross wrote:
On 03/19/2015 05:18 PM, David Vrabel wrote:
On 19/03/15 14:31, Juergen Gross wrote:
Commit 054954eb051f35e74b75a566a96fe756015352c8 (xen: switch to linear
virtual mapped sparse p2m list) introduced a regression regarding to
memory hotplug for a pv
to disable QUEUE_SPINLOCKS when supported by
the arch, is this intentional? If so, the existing ticketlock code could go.
David
8--
x86/xen: paravirt support for qspinlocks
Provide the wait and kick ops necessary for paravirt-aware queue
spinlocks.
Signed-off-by: David
On 19/03/15 14:31, Juergen Gross wrote:
Commit 054954eb051f35e74b75a566a96fe756015352c8 (xen: switch to linear
virtual mapped sparse p2m list) introduced a regression regarding to
memory hotplug for a pv-domain: as the virtual space for the p2m list
is allocated for the to be expected memory
On 19/03/15 14:31, Juergen Gross wrote:
Commit 25b884a83d487fd62c3de7ac1ab5549979188482 (x86/xen: set
regions above the end of RAM as 1:1) introduced a regression.
To be able to add memory pages which were added via memory hotplug to
a pv domain, the pages must be invalid instead of identity
On 11/03/15 13:52, Jan Beulich wrote:
> It's not clear to me why only the enabling operation got handled so
> far.
Applied to devel/for-linus-4.1, thanks.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On 17/02/15 07:02, Juergen Gross wrote:
> Up to now the pvscsi frontend hasn't supported domain suspend and
> resume. When a domain with an assigned pvscsi device was suspended
> and resumed again, it was not able to use the device any more: trying
> to do so resulted in hanging processes.
>
>
On 17/02/15 07:02, Juergen Gross wrote:
> When a xen domain is being restored the LUN state of a pvscsi device
> is "Connected" and not "Initialising" as in case of attaching a new
> pvscsi LUN.
>
> This must be taken into account when adding a new pvscsi device for
> a domain as otherwise the
On 10/03/15 20:49, Tao Chen wrote:
> Add the {xen-pvscsi: } prefix in pr_fmt and remove DPRINTK, then
> replace all DPRINTK with pr_debug.
>
> Also fixed up some comments just as eliminate redundant whitespace
> and format the code.
>
> These will make the code easier to read.
Applied to
On 16/03/15 13:16, Peter Zijlstra wrote:
> Hi Waiman,
>
> As promised; here is the paravirt stuff I did during the trip to BOS last
> week.
>
> All the !paravirt patches are more or less the same as before (the only real
> change is the copyright lines in the first patch).
>
> The paravirt
On 16/03/15 13:16, Peter Zijlstra wrote:
Hi Waiman,
As promised; here is the paravirt stuff I did during the trip to BOS last
week.
All the !paravirt patches are more or less the same as before (the only real
change is the copyright lines in the first patch).
The paravirt stuff is
On 11/03/15 13:52, Jan Beulich wrote:
It's not clear to me why only the enabling operation got handled so
far.
Applied to devel/for-linus-4.1, thanks.
David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On 17/02/15 07:02, Juergen Gross wrote:
Up to now the pvscsi frontend hasn't supported domain suspend and
resume. When a domain with an assigned pvscsi device was suspended
and resumed again, it was not able to use the device any more: trying
to do so resulted in hanging processes.
Support
On 17/02/15 07:02, Juergen Gross wrote:
When a xen domain is being restored the LUN state of a pvscsi device
is Connected and not Initialising as in case of attaching a new
pvscsi LUN.
This must be taken into account when adding a new pvscsi device for
a domain as otherwise the pvscsi LUN
On 10/03/15 20:49, Tao Chen wrote:
Add the {xen-pvscsi: } prefix in pr_fmt and remove DPRINTK, then
replace all DPRINTK with pr_debug.
Also fixed up some comments just as eliminate redundant whitespace
and format the code.
These will make the code easier to read.
Applied to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
stable/for-linus-4.0-rc3-tag
xen: bug fixes for 4.0-rc3
- - Fix a PV regression in 3.19.
- - Fix a dom0 crash on hosts with large numbers of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
stable/for-linus-4.0-rc3-tag
xen: bug fixes for 4.0-rc3
- - Fix a PV regression in 3.19.
- - Fix a dom0 crash on hosts with large numbers of
On 11/03/15 14:42, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 11, 2015 at 01:52:00PM +, Jan Beulich wrote:
>> It's not clear to me why only the enabling operation got handled so
>> far.
>
> Reviewed-by: Konrad Rzeszutek Wilk
With no reports that this actually fixes anything, do we want this
On 11/03/15 13:51, Jan Beulich wrote:
> Otherwise the guest can abuse that control to cause e.g. PCIe
> Unsupported Request responses (by disabling memory and/or I/O decoding
> and subsequently causing [CPU side] accesses to the respective address
> ranges), which (depending on system
On 11/03/15 13:51, Jan Beulich wrote:
Otherwise the guest can abuse that control to cause e.g. PCIe
Unsupported Request responses (by disabling memory and/or I/O decoding
and subsequently causing [CPU side] accesses to the respective address
ranges), which (depending on system configuration)
On 11/03/15 14:42, Konrad Rzeszutek Wilk wrote:
On Wed, Mar 11, 2015 at 01:52:00PM +, Jan Beulich wrote:
It's not clear to me why only the enabling operation got handled so
far.
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
With no reports that this actually fixes anything,
On 06/03/15 15:36, Oleg Nesterov wrote:
> On 03/06, David Vrabel wrote:
>>
>> On 06/03/15 14:01, Oleg Nesterov wrote:
>>
>>> Not sure I understand it correctly after the first quick look, but
>>>
>>> 1. It conflicts with the recent changes in tip/
d_fpu_begin() is
>>>not nice too. It will do __save_init_fpu() and this overwrites
>>>->fpu.state too.
>>>
>>> Starting from v4.0 it does kernel_fpu_disable(), but the older kernels
>>> do not.
>>>
>>> Ingo, this code is
On 26/02/15 05:52, Juergen Gross wrote:
> Using the pvops kernel a NULL pointer dereference was detected on a
> large machine (144 processors) when booting as dom0 in
> evtchn_fifo_unmask() during assignment of a pirq.
>
> The event channel in question was the first to need a new entry in
>
later allocate during
the first usage of FPU. So this free/allocate might be slower
for some workloads.
c. math_state_restore() is called from multiple places
and it is error pone if the caller expects interrupts to be disabled
throughout the execution of math_state_restore(). Can lead to subtle
bug
() is
not nice too. It will do __save_init_fpu() and this overwrites
-fpu.state too.
Starting from v4.0 it does kernel_fpu_disable(), but the older kernels
do not.
Ingo, this code is really horrible and fragile. We need to cleanup it
step-by-step, imho.
How about the patch from David Vrabel
and the code complexity
introducing subtle bugs is not worth it. So remove
the logic of non-eager fpu mem allocation at the first usage.
Signed-off-by: Suresh Siddha sbsid...@gmail.com
Signed-off-by: David Vrabel david.vra...@citrix.com
---
v4:
- add __ref to fpu_init() which needs to allocate the fpu
On 26/02/15 05:52, Juergen Gross wrote:
Using the pvops kernel a NULL pointer dereference was detected on a
large machine (144 processors) when booting as dom0 in
evtchn_fifo_unmask() during assignment of a pirq.
The event channel in question was the first to need a new entry in
On 06/03/15 15:36, Oleg Nesterov wrote:
On 03/06, David Vrabel wrote:
On 06/03/15 14:01, Oleg Nesterov wrote:
Not sure I understand it correctly after the first quick look, but
1. It conflicts with the recent changes in tip/x86/fpu
2. fpu_ini() initializes current-thread.fpu.state
On 04/03/15 14:55, Boris Ostrovsky wrote:
>
> In the meantime, it turned out that HVM guests are broken by this patch
> (with our without changes that we've been discussing), because HVM CPUs
> die with
>
> static void xen_hvm_cpu_die(unsigned int cpu)
> {
> xen_cpu_die(cpu);
>
On 04/03/15 14:09, Juergen Gross wrote:
>
> The main question whether it is worth to consider this alternative is
> the performance aspect. Does anyone have an idea which USB devices would
> typically be used via pvusb? I'd suspect memory sticks and USB disks
> and perhaps webcams being the most
801 - 900 of 2368 matches
Mail list logo
