On 9/19/18 9:42 AM, Juergen Gross wrote:
> When a driver domain (e.g. dom0) is running out of maptrack entries it
> can't map any more foreign domain pages. Instead of silently stalling
> the affected domUs issue a rate limited warning in this case in order
> to make it easier to detect that situat
iggered in
get_free_grant(). This can be observed even on an idle system, within
20-30 minutes.
We should keep the grants in the buffer when purging, and only free the
grant ref.
Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
Signed-off-by: Boris Ostrovsky
---
drivers/bloc
On 9/20/18 10:39 AM, Jens Axboe wrote:
> On 9/20/18 12:29 AM, Christoph Hellwig wrote:
>> On Sat, Sep 15, 2018 at 08:47:13AM -0600, Jens Axboe wrote:
> this series moves various helpers related to merging based on physical
> addresses from the public headers into block/, moves the Xen speci
On 9/23/18 1:38 PM, Nicolai Stange wrote:
> arch/x86/include/asm/xen/events.h references xen_hvm_domain() from the
> inlined xen_support_evtchn_rebind().
>
> xen_hvm_domain() gets #defined in include/xen/xen.h and
> arch/x86/include/asm/xen/events.h doesn't include that.
>
> On current Linus' tree,
On 9/25/18 1:14 AM, Dongli Zhang wrote:
>
> So far we have: (1) domain hash table, (2) domain list (where duplicate
> entries
> may exist) and (3) purge list.
>
> Can I assume you would like to discard the domain list and only keep domain
> hash
> table and purge list?
Yes, that's what I was thi
t; could not select the option. With the new Kconfig, we default y for
> Dom0 and n for DomU. Either can then toggle the selection.
>
> Signed-off-by: Jason Andryuk
Reviewed-by: Boris Ostrovsky
Applied to for-linus-19d
___
Xen-devel mailing lis
On 9/26/18 4:43 AM, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/xen/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 90d387b50ab747f5..7f42d41f66ee98e3 100644
> --- a/drivers/xen/Kc
On 9/27/18 2:56 PM, Jens Axboe wrote:
> On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
>> On 27/09/18 16:26, Jens Axboe wrote:
>>> On 9/27/18 1:12 AM, Juergen Gross wrote:
>>>> On 22/09/18 21:55, Boris Ostrovsky wrote:
>>>>> Commit a46b53672b2c (&
On 9/27/18 5:37 PM, Jens Axboe wrote:
> On 9/27/18 2:33 PM, Sander Eikelenboom wrote:
>> On 27/09/18 21:06, Boris Ostrovsky wrote:
>>> On 9/27/18 2:56 PM, Jens Axboe wrote:
>>>> On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
>>>>> On 27/09/18 16:26
On 9/28/18 3:28 AM, Juergen Gross wrote:
> Commit a46b53672b2c2e3770b38a4abf90d16364d2584b ("xen/blkfront: cleanup
> stale persistent grants") introduced a regression as purged persistent
> grants were not pu into the list of free grants again. Correct that.
>
> Signed-off-by: Juergen Gross
> ---
On 9/28/18 9:13 AM, Juergen Gross wrote:
> On 28/09/2018 14:45, Boris Ostrovsky wrote:
>> On 9/28/18 3:28 AM, Juergen Gross wrote:
>>> Commit a46b53672b2c2e3770b38a4abf90d16364d2584b ("xen/blkfront: cleanup
>>> stale persistent grants") introduced a regression
On 9/28/18 9:52 AM, Juergen Gross wrote:
> On 28/09/2018 15:33, Boris Ostrovsky wrote:
>> On 9/28/18 9:13 AM, Juergen Gross wrote:
>>> On 28/09/2018 14:45, Boris Ostrovsky wrote:
>>>> On 9/28/18 3:28 AM, Juergen Gross wrote:
>>>>> Commit a46b53672b
On 10/1/18 9:12 AM, Andrew Cooper wrote:
> On 01/10/18 12:13, Jan Beulich wrote:
> On 01.10.18 at 11:58, wrote:
>>> Having the allocator return unscrubbed pages is a potential security
>>> concern: some domain can be given pages with memory contents of another
>>> domain. This may happen, for
On 10/1/18 9:50 AM, George Dunlap wrote:
> On 10/01/2018 02:44 PM, Boris Ostrovsky wrote:
>> On 10/1/18 9:12 AM, Andrew Cooper wrote:
>>> On 01/10/18 12:13, Jan Beulich wrote:
>>>>>>> On 01.10.18 at 11:58, wrote:
>>>>> Having the all
r nowadays than we did in the past, we're still
>> not quite there to guarantee hardware like behavior in all cases
>> anyway. Nothing is getting worse by the changes made here, afaict.
>>
>> Signed-off-by: Jan Beulich
>> Acked-by: Tim Deegan
>> Reviewed-by: Paul Durrant
> SVM and VMX maintainers?
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
endor "save" hook, eliminating the need for the hook
> functions to zero individual fields.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky https://lists.xenproject.org/mailman/listinfo/xen-devel
Xend-based toolstacks don't have static-max entry in xenstore. The
equivalent node for those toolstacks is memory_static_max.
Fixes: 5266b8e4445c (xen: fix booting ballooned down hvm guest)
Signed-off-by: Boris Ostrovsky
Cc: # 4.13
---
drivers/xen/xen-balloon.c | 13 -
1
On 10/3/18 11:51 AM, Pasi Kärkkäinen wrote:
> On Wed, Sep 19, 2018 at 11:05:26AM +0200, Roger Pau Monné wrote:
>> On Tue, Sep 18, 2018 at 02:09:53PM -0400, Boris Ostrovsky wrote:
>>> On 9/18/18 5:32 AM, George Dunlap wrote:
>>>>> On Sep 18, 2018, at 8:15 AM, Pasi
On 10/9/18 6:54 AM, Juergen Gross wrote:
> +
> +u64 x86_default_get_root_pointer(void)
> +{
> + return boot_params.hdr.acpi_rsdp_addr;
> +}
Should we then update init_pvh_bootparams() with
pvh_bootparams.hdr.acpi_rsdp_addr = pvh_start_info.rsdp_paddr;
(and drop x86_init.acpi.get_root_po
On 10/9/18 6:41 AM, Christian Borntraeger wrote:
>
>
> On 10/09/2018 11:54 AM, Filippo Sironi wrote:
>> Start populating /sys/hypervisor with KVM entries when we're running on
>> KVM. This is to replicate functionality that's available when we're
>> running on Xen.
>>
>> Let's start with /sys/hyp
On 10/10/18 11:53 AM, Juergen Gross wrote:
> On 10/10/2018 17:09, Joao Martins wrote:
>> On 10/09/2018 05:09 PM, Juergen Gross wrote:
>>> xenbus_va_dev_error() will try to write error messages to Xenstore
>>> under the error//error node (with something like
>>> "device/vbd/51872"). This will fail
On 10/15/18 6:36 AM, Andrew Cooper wrote:
>
> @@ -567,7 +573,10 @@ struct arch_vcpu
> void *fpu_ctxt;
> unsigned long vgc_flags;
> struct cpu_user_regs user_regs;
> -unsigned long debugreg[8];
> +
> +/* Debug registers. */
> +unsigned long dr[4],
On 10/15/18 9:32 AM, Andrew Cooper wrote:
> On 15/10/18 14:28, Boris Ostrovsky wrote:
>> On 10/15/18 6:36 AM, Andrew Cooper wrote:
>>>
>>> @@ -567,7 +573,10 @@ struct arch_vcpu
>>> void *fpu_ctxt;
>>> unsigned long vgc_f
le")" so it can be
> picked up for backporting.
SoB would also be good to have ;-)
Reviewed-by: Boris Ostrovsky
>
> Acked-by: Julien Grall
>
> Cheers,
>>
>> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
>> index fd18c97..939a962 10064
gt;> In addition to describing this corner case in the SVM side, extend the
>> comment
>> for the same fix on the VT-x side. (I have a suspicion that I've just worked
>> out why VT-x doesn't tolerate LMA != LME when Unrestricted Guest is clear.)
>>
>> Si
design.
> Xen doesn't use the fields at all, except to copy them on virtual
> vmentry/vmexit.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 10/17/18 9:44 AM, Stefano Stabellini wrote:
> It would be good for me to keep an eye on the patches that touch Xen
> support in Linux to try to spot changes that break Xen on ARM early on.
>
> Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
>
> diff --g
On 10/19/18 11:14 AM, Andrew Cooper wrote:
> diff --git a/xen/include/asm-x86/msr.h b/xen/include/asm-x86/msr.h
> index 7a061b2..c1cb38f 100644
> --- a/xen/include/asm-x86/msr.h
> +++ b/xen/include/asm-x86/msr.h
> @@ -287,6 +287,12 @@ struct vcpu_msrs
> bool cpuid_faulting:1;
>
involve swapping if and else in the former.
>
> Does that sound correct?
>
>> Thank you Boris for pointing it out.
>>
> Fixes: 4855c92dbb7 ("xen-sw..") ?
>
>> Signed-off-by: Joe Jin
>> Cc: Konrad Rzeszutek Wilk
>> Cc: Boris Ostrovsky
> Repo
On 10/24/18 10:43 AM, Joe Jin wrote:
> On 10/24/18 6:57 AM, Boris Ostrovsky wrote:
>> On 10/24/18 9:02 AM, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Oct 23, 2018 at 08:09:04PM -0700, Joe Jin wrote:
>>>> Commit 4855c92dbb7 "xen-swiotlb: fix the check condition
he boot message:
>
> [0.00] Xen Platform PCI: unrecognised magic value
>
> Cc: # 4.11
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 10/25/18 8:36 AM, Juergen Gross wrote:
> On 11/10/2018 13:03, Joao Martins wrote:
>> On 10/11/2018 06:05 AM, Juergen Gross wrote:
>>> On 10/10/2018 18:57, Boris Ostrovsky wrote:
>>>> On 10/10/18 11:53 AM, Juergen Gross wrote:
>>>>> On 10/10/2018 17
On 10/25/18 10:23 AM, Joe Jin wrote:
> On 10/25/18 4:45 AM, Boris Ostrovsky wrote:
>> On 10/24/18 10:43 AM, Joe Jin wrote:
>>> On 10/24/18 6:57 AM, Boris Ostrovsky wrote:
>>>> On 10/24/18 9:02 AM, Konrad Rzeszutek Wilk wrote:
>>>>> On Tue, Oc
On 02/01/2018 03:57 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Current xenbus frontend driver removal flow first disconnects
> the driver from xenbus and then calls driver's remove callback.
> This makes it impossible for the driver to listen to backend's
> state change
dy.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 02/01/2018 03:24 PM, Oleksandr Andrushchenko wrote:
>
>
> On 02/01/2018 10:08 PM, Boris Ostrovsky wrote:
>> On 02/01/2018 03:57 AM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko
>>>
>>> Current xenbus frontend driver removal flow fi
On 02/02/2018 10:32 AM, Arnd Bergmann wrote:
> The legacy hypercall handlers were originally added with
> a comment explaining that "copying the argument structures in
> HYPERVISOR_event_channel_op() and HYPERVISOR_physdev_op() into the local
> variable is sufficiently safe" and only made sure to n
Woods
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 01/31/2018 03:35 PM, Brian Woods wrote:
Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.
Reported-by: Andrew Cooper
Signed-off-by: Brian Woods
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel
On 01/31/2018 03:35 PM, Brian Woods wrote:
Corrects some EFER.SVME checks in intercepts. See AMD APM vol2 section
15.4 for more details. VMMCALL isn't checked due to guests needing it
to boot.
Don't you need SVME be on for VMMCALL?
-boris
___
On 02/03/2018 10:12 AM, Arnd Bergmann wrote:
On Sat, Feb 3, 2018 at 12:33 AM, Boris Ostrovsky
wrote:
On 02/02/2018 10:32 AM, Arnd Bergmann wrote:
The legacy hypercall handlers were originally added with
a comment explaining that "copying the argument structur
On 02/03/2018 12:10 PM, Andrew Cooper wrote:
On 03/02/18 17:03, Boris Ostrovsky wrote:
On 01/31/2018 03:35 PM, Brian Woods wrote:
Corrects some EFER.SVME checks in intercepts. See AMD APM vol2 section
15.4 for more details. VMMCALL isn't checked due to guests needing it
to boot.
On 02/04/2018 10:35 AM, Arnd Bergmann wrote:
On Sat, Feb 3, 2018 at 6:08 PM, Boris Ostrovsky
wrote:
On 02/03/2018 10:12 AM, Arnd Bergmann wrote:
On Sat, Feb 3, 2018 at 12:33 AM, Boris Ostrovsky
wrote:
On 02/02/2018 10:32 AM, Arnd Bergmann wrote:
The legacy hypercall handlers were
On 02/02/2018 08:34 PM, Stefano Stabellini wrote:
When the client sends a regular blocking accept request, the backend is
expected to return only when the accept is completed, simulating a
blocking behavior, or return an error.
Specifically, on EAGAIN from inet_accept, the backend shouldn't re
On 02/05/2018 01:01 PM, Stefano Stabellini wrote:
> On Sun, 4 Feb 2018, Boris Ostrovsky wrote:
>> On 02/02/2018 08:34 PM, Stefano Stabellini wrote:
>>> When the client sends a regular blocking accept request, the backend is
>>> expected to return only when the accept
by: Prarit Bhargava
Tested-and-reported-by: Simon Gaiser
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Dou Liyang
Cc: Prarit Bhargava
Cc: Kate Stewart
Cc: Greg Kroah-Hartman
Cc: Andy Lutomirski
Cc: Andi Kleen
On 02/08/2018 10:25 AM, Alexandru Isaila wrote:
+
+ rc = hvm_monitor_debug(regs->rip,
+ HVM_MONITOR_SOFTWARE_BREAKPOINT,
+ X86_EVENTTYPE_SW_EXCEPTION,
+ inst_len);
+ if ( rc <
sidering a transaction closed if we have sent XS_TRANSACTION_END once
regardless of the return code.
Cc: # 4.11
Fixes: fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent xenstore
accesses")
Signed-off-by: Simon Gaiser
Reviewed-by: Boris Ostrovsky
(although I'd pref
On 02/07/2018 05:22 PM, Simon Gaiser wrote:
As the previous commit shows it's quite easy to confuse the transaction
reference counting by ending a transaction twice. So at least try to
detect and report it.
Signed-off-by: Simon Gaiser
---
drivers/xen/xenbus/xenbus_xs.c | 9 +
1 fil
(Resending)
On 02/10/2018 11:30 AM, Boris Ostrovsky wrote:
>
>
> On 02/08/2018 10:25 AM, Alexandru Isaila wrote:
>> This commit separates the svm caps from the vmx caps.
>>
>> Signed-off-by: Alexandru Isaila
>>
>> ---
>> Changes since V1:
>>
(Resending too. Something was wrong with my client)
On 02/10/2018 11:33 AM, Boris Ostrovsky wrote:
On 02/08/2018 10:25 AM, Alexandru Isaila wrote:
This commit enables MSR events for svm.
Signed-off-by: Alexandru Isaila
Reviewed-by: Boris Ostrovsky
On 02/10/2018 08:27 PM, Simon Gaiser wrote:
Boris Ostrovsky:
On 02/07/2018 05:22 PM, Simon Gaiser wrote:
+users_old = xs_state_users;
xs_state_users--;
if ((req->type == XS_TRANSACTION_START && req->msg.type == XS_ERROR) ||
req->type == X
On 02/08/2018 10:25 AM, Alexandru Isaila wrote:
This commit enables MSR events for svm.
Signed-off-by: Alexandru Isaila
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org
On 02/08/2018 10:25 AM, Alexandru Isaila wrote:
This commit separates the svm caps from the vmx caps.
Signed-off-by: Alexandru Isaila
---
Changes since V1:
- Removed the if ( cpu_has_svm )
---
xen/include/asm-x86/monitor.h | 34 +++---
1 file changed, 1
On 02/15/2018 05:22 AM, Alexandru Isaila wrote:
> Hi all,
>
> This series provides a skeleton for enabling vm_events on SVM. For the
> first step, the MSR, CR, Breakpoint and GuestRequest have been tested
> and added to the capabilities list.
>
Reviewed-b
On 02/20/2018 05:00 PM, Brian Woods wrote:
> I've seen patch 1 and 3 are in but this one isn't. Any status on it?
>
That's possibly because you needed an SVM maintainer ACK.
I think Jan was waiting for decision on how to present the ASSERT. From
the 3 options I slightly more prefer
ASSERT(neste
On 02/20/2018 05:27 PM, Brian Woods wrote:
> Only enable virtual VMLOAD/SAVE and VGIF if the guest EFER.SVME is set.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Brian Woods
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing li
On 02/20/2018 03:56 AM, Roger Pau Monne wrote:
> At the moment this is currently set at VMC{S/B} creation and not changed,
> but further patches are going to change the CR4 mask at runtime.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Boris Ostrovsky
> Cc: Suravee Sut
On 02/21/2018 03:27 AM, Roger Pau Monné wrote:
> On Tue, Feb 20, 2018 at 07:23:44PM -0500, Boris Ostrovsky wrote:
>> On 02/20/2018 03:56 AM, Roger Pau Monne wrote:
>>> At the moment this is currently set at VMC{S/B} creation and not changed,
>>> but further patches are g
n that
> most of the callers are now switched to _mfn(domain_page_to_mfn(...)).
>
> Signed-off-by: Julien Grall
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
hvm/svm/svm.h | 5 -
> xen/include/asm-x86/hvm/svm/vmcb.h | 3 ++-
> 4 files changed, 10 insertions(+), 2 deletions(-)
>
IIRC previous count value (3000) was somewhat arbitrary so
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
X
mit 013e34f5a6 ("x86: handle paged gfn in
> wrmsr_hypervisor_regs") was probably okay, since prior to that the
> return value wasn't checked at all. But that's not how we want things
> to be handled nowadays.
>
> Si
On 02/21/2018 05:18 AM, Alexandru Isaila wrote:
> At this moment the CPUID events for the AMD architecture are not
> forwarded to the monitor layer.
>
> This patch adds the CPUID event to the common capabilities and then
> forwards the event to the monitor layer.
>
> ---
> Changes since V1:
>
On 02/22/2018 10:44 AM, Jan Beulich wrote:
On 22.02.18 at 15:53, wrote:
>> On 22/02/18 13:44, Jan Beulich wrote:
>>> ... for unknown MSRs: wrmsr_hypervisor_regs()'s comment clearly says
>>> that the function returns 0 for unrecognized MSRs, so
>>> {svm,vmx}_msr_write_intercept() should not co
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
> +static struct xenbus_driver xen_driver = {
> + .ids = xen_drv_ids,
> + .probe = xen_drv_probe,
> + .remove = xen_drv_remove,
> + .otherend_changed = backend_on_changed,
What does "_on_" stand for?
-boris
__
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
> +
> +static int cfg_connector(struct xen_drm_front_info *front_info,
> + struct xen_drm_front_cfg_connector *connector,
> + const char *path, int index)
> +{
> + char *connector_path;
> +
> + connector_path = d
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
> +
> +static irqreturn_t evtchnl_interrupt_ctrl(int irq, void *dev_id)
> +{
> + struct xen_drm_front_evtchnl *evtchnl = dev_id;
> + struct xen_drm_front_info *front_info = evtchnl->front_info;
> + struct xendispl_resp *resp;
> +
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
>
> static int __init xen_drv_init(void)
> {
> + /* At the moment we only support case with XEN_PAGE_SIZE == PAGE_SIZE */
> + BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE);
Why BUILD_BUG_ON? This should simply not load if page sizes ar
On 02/23/2018 02:53 AM, Oleksandr Andrushchenko wrote:
> On 02/23/2018 02:25 AM, Boris Ostrovsky wrote:
>> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
>>> static int __init xen_drv_init(void)
>>> {
>>> +/* At the moment we only support case
On 02/23/2018 01:37 AM, Oleksandr Andrushchenko wrote:
> On 02/23/2018 12:23 AM, Boris Ostrovsky wrote:
>> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
>>> +static struct xenbus_driver xen_driver = {
>>> +.ids = xen_drv_ids,
>>> +.pro
On 02/23/2018 02:00 AM, Oleksandr Andrushchenko wrote:
> On 02/23/2018 01:50 AM, Boris Ostrovsky wrote:
>> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
>>> +
>>> +static irqreturn_t evtchnl_interrupt_ctrl(int irq, void *dev_id)
>>> +{
>>&g
gt; Changes since V2:
> - Pass the inst_len to svm_vmexit_do_cpuid()
>
> Signed-off-by: Alexandru Isaila
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
> +
> +struct drm_driver xen_drm_driver = {
> + .driver_features = DRIVER_GEM | DRIVER_MODESET |
> + DRIVER_PRIME | DRIVER_ATOMIC,
> + .lastclose = lastclose,
> + .gem_free
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
> +static struct xen_gem_object *gem_create(struct drm_device *dev, size_t size)
> +{
> + struct xen_drm_front_drm_info *drm_info = dev->dev_private;
> + struct xen_gem_object *xen_obj;
> + int ret;
> +
> + size = round_up(size,
On 02/26/2018 06:08 AM, Juergen Gross wrote:
> Today the hvc console is added as a preferred console for pv domUs
> only. As this requires a boot parameter for getting dom0 messages per
> default add it for dom0, too.
>
> Signed-off-by: Juergen Gross
> ---
> arch/x86/xen/enlighten_pv.c | 4 +++-
>
very appropriate.
>
> Update them to take a vcpu pointer rather than presuming that they act on
> current, which is safe for all implemented operations. Also update them to
> use X86EMUL_* return values.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Jun
7;t very appropriate.
>
> Update them to take a vcpu pointer rather than presuming that they act on
> current, and switch to using X86EMUL_* return values.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Jun Nakajima
> CC: Paul Durrant
> CC: Kevin Tian
On 02/26/2018 02:12 PM, Andrew Cooper wrote:
> On 20/02/18 11:58, Andrew Cooper wrote:
>> This rats nest was discovered when finding that MSR_TSC_AUX leaked into PV
>> guests. It is RFC because I haven't done extensive testing on the result,
>> and
>> because there are some functional changes for
e common case.
>
> To amortise overhead cost, introduce wrmsr_tsc_aux() which performs a lazy
> update of the MSR, and use this function consistently across the codebase.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Jun Nakajima
> CC: Kevin Tian
> CC:
Reported-by: Hooman Mirhadi
> CC:
> CC: Roger Pau Monné
> CC: David Vrabel
> CC: Boris Ostrovsky
> CC: Eduardo Valentin
> CC: Juergen Gross
> CC: Thomas Gleixner
> CC: "K. Y. Srinivasan"
> CC: Liu Shuo
> CC: Anoob Soman
> Signed-off-by: Amit Sha
On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote:
> On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:
>> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
>>> +static struct xen_gem_object *gem_create(struct drm_device *dev,
>>> size_t size)
>>> +{
&g
On 02/27/2018 03:39 AM, Jan Beulich wrote:
On 23.02.18 at 08:55, wrote:
> On 22.02.18 at 23:16, wrote:
>>> On 02/22/2018 10:44 AM, Jan Beulich wrote:
>>> On 22.02.18 at 15:53, wrote:
> On 22/02/18 13:44, Jan Beulich wrote:
>> ... for unknown MSRs: wrmsr_hypervisor_regs()'s c
On 02/27/2018 05:19 AM, Juergen Gross wrote:
> Today the tty0 and hvc0 consoles are added as a preferred consoles for
> pv domUs only. As this requires a boot parameter for getting dom0
> messages per default, add them for dom0, too.
>
> Signed-off-by: Juergen Gross
Reviewed-by:
On 02/27/2018 02:54 PM, Stefano Stabellini wrote:
> We are using test_and_* operations on the status and flag fields of
> struct sock_mapping. However, these functions require the operand to be
> 64-bit aligned on arm64. Currently, only status is 64-bit aligned.
>
> Make flags 64-bit aligned by int
On 02/27/2018 04:32 PM, Stefano Stabellini wrote:
> On Tue, 27 Feb 2018, Boris Ostrovsky wrote:
>> On 02/27/2018 02:54 PM, Stefano Stabellini wrote:
>>> We are using test_and_* operations on the status and flag fields of
>>> struct sock_mapping. However, these function
gt; Fixes: 4892c9b4ada9f9 ("xen: add support for MSI message groups")
>> Reported-by: Hooman Mirhadi
>> Signed-off-by: Roger Pau Monné
>> ---
>> Cc: Boris Ostrovsky
>> Cc: Juergen Gross
>> Cc: Amit Shah
>> CC: sta...@vger.kernel.org
>
)
>
> Signed-off-by: Jason Andryuk
> Cc: Eduardo Otubo
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
gt;
>> Signed-off-by: Razvan Cojocaru
>> Reported-by: Bitweasil
>> Suggested-by: Andrew Cooper
>> Acked-by: Tamas K Lengyel
>> Reviewed-by: Jan Beulich
>> Reviewed-by: Kevin Tian
>> Acked-by: George Dunlap
> Boris / Suvaree, any opinions on the S
On 02/27/2018 01:52 AM, Oleksandr Andrushchenko wrote:
> On 02/27/2018 01:47 AM, Boris Ostrovsky wrote:
>> On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote:
>>> On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:
>>>> On 02/21/2018 03:03 AM, Oleksandr Andrushchenk
-bit aligned.
Signed-off-by: Stefano Stabellini
Reviewed-by: Boris Ostrovsky
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 02/28/2018 01:27 PM, Maran Wilson wrote:
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index eb7f43f23521..fa7cd0305125 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -791,6 +791,14 @@ config KVM_GUEST
> underlying device model, the host provides the guest with
>
On 02/28/2018 01:28 PM, Maran Wilson wrote:
> We need to refactor PVH entry code so that support for other hypervisors
> like Qemu/KVM can be added more easily.
>
> This patch moves the small block of code used for initializing Xen PVH
> virtual machines into the Xen specific file. This initializat
On 03/01/2018 03:46 AM, Paolo Bonzini wrote:
> On 01/03/2018 07:11, Juergen Gross wrote:
>>> Probably a better place for these would be
>>> arch/x86/platform/pvh/{enlighten.c,head.S}. (Just because there are no
>>> .c or .S files in arch/x86).
>> Right.
>>
>>> Maybe Xen ought to be moved under
>>>
I is enabled.
>
> Reported-by: Jan Beulich
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Wei Liu
> Cc: Boris Ostrovsky
> Cc: Suravee Suthikulpanit
> Cc: Brian Woods
Reviewed-by: Boris Ostrovsky
___
On 11/6/18 7:07 AM, Sergey Dyasli wrote:
> As a convenient helper function and refactor the code to use it.
>
> No functional change.
>
> Signed-off-by: Sergey Dyasli
> ---
> CC: Boris Ostrovsky
> CC: Suravee Suthikulpanit
> CC: Brian Woods
>
> v2:
>
On 11/7/18 5:49 AM, Daniel Kiper wrote:
> On Tue, Nov 06, 2018 at 09:54:54AM -0700, Jan Beulich wrote:
> On 02.11.18 at 18:59, wrote:
>>> It’s time again for the x86 community call: for the agenda see
>>> https://docs.google.com/document/d/1RxW-iwcFFuKzNjjEqLEtiwFVHgAUlk35c0EtTkRE1
>>> k4/edit
On 11/7/18 4:30 AM, Sander Eikelenboom wrote:
> Hi Juergen / Boris,
>
> Last week i tested Linux kernel 4.19.0 stable with the Xen "for-linus-4.20"
> branch pulled on top.
> Unfortunately i was seeing guests lockup after some time, see below for the
> logging from one of the guest
> which i was a
On 11/7/18 5:45 PM, Sander Eikelenboom wrote:
> On 07/11/18 23:34, Boris Ostrovsky wrote:
>> On 11/7/18 4:30 AM, Sander Eikelenboom wrote:
>>> Hi Juergen / Boris,
>>>
>>> Last week i tested Linux kernel 4.19.0 stable with the Xen "for-linus-4.20"
>
On 11/9/18 2:03 AM, Juergen Gross wrote:
> Ping?
>
> Jan's remark regarding de-privileged qemu is no issue as the hypercall
> node is being closed by the de-privilege library function.
Reviewed-by: Boris Ostrovsky
___
Xen-devel
tatic DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
> static DEFINE_PER_CPU(char *, irq_name);
> +static DEFINE_PER_CPU(atomic_t, xen_qlock_wait_nest);
I'd move this to xen_qlock_wait().
Either way,
Reviewed-by: Boris Ostrovsky
> static bool xen_pvspin = true;
>
> s
501 - 600 of 1149 matches
Mail list logo
