On 24/08/17 18:12, Julien Grall wrote:
> Hello,
>
> I was expecting to be CCed on this patch.
Oops, sorry for that.
>
> On 21/08/17 19:05, Juergen Gross wrote:
>> The x86 and arm versions of XENMAPSPACE_grant_table handling are nearly
>> identical. Move the code into a function in grant_table.c
flight 112858 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112858/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
112676
Tests whic
When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are under
the scope of the same VT-d unit as the 'Physical Function'. A 'Physical
Function' can be a 'Traditional Function' or an ARI 'Extended Function'.
And furthermore, 'Extended Functions' on an endpoint are under the scope of
I have sent out a new version, let's skip this one.
Thanks
Chao
On Fri, Aug 25, 2017 at 12:17:15PM +0800, Chao Gao wrote:
>When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are under
>the scope of the same VT-d unit as the 'Physical Function'. A 'Physical
>Function' can be a 'T
From 3aa2541108f28cfdf0f3bf47ddae9b762b73b532 Mon Sep 17 00:00:00 2001
From: Chao Gao
Date: Mon, 7 Aug 2017 04:50:04 +0800
Subject: [PATCH v9] VT-d: use correct BDF for VF to search VT-d unit
When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are under
the scope of the same VT-d
Hi,
I have downloaded Xen project 4.8.0. I just want to learn Grant table
mechanism , but I can't find any examples regarding how to do it. Could you
please provide any examples?
Regards
Sai Krishna vp
___
Xen-devel mailing list
Xen-devel@lists.xen.
flight 112857 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112857/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 3 capture-logs broken REGR. vs. 112102
When SR-IOV is enabled, 'Virtual Functions' of a 'Physical Function' are under
the scope of the same VT-d unit as the 'Physical Function'. A 'Physical
Function' can be a 'Traditional Function' or an ARI 'Extended Function'.
And furthermore, 'Extended Functions' on an endpoint are under the scope of
flight 112859 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112859/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 279c01ce13739f0fd8ec3e7652299f6873fc14a9
baseline version:
ovmf e4d409c6e3b96738fb0c7
On 2017年08月24日 19:08, Wei Liu wrote:
If add dmar table for hvmlite, we should combine dmar table with other
> >> ACPI table and populate into acpi_modules[2]. This is how hvmlite add
> >> other ACPI tables in libxl__dom_load_acpi().
> >>
>>> > >
>>> > > Sure, that sounds plausi
flight 112855 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112855/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 7 reboot fail REGR. vs. 112809
test-amd64-i386-fr
On Thu, 24 Aug 2017, Roger Pau Monne wrote:
> When a MSI interrupt is bound to a guest using
> xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
> left masked by default.
>
> This causes problems with guests that first configure interrupts and
> clean the per-entry MSIX table mask
flight 112854 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112854/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 112800
test-amd64-amd64-xl-rtds 7
flight 112853 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112853/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 10 debian-install fail REGR. vs. 110515
test-amd64-amd64-xl
On Thu, 24 Aug 2017 14:13:38 -0700
Thomas Garnier wrote:
> With the fix for function tracing, the hackbench results have an
> average of +0.8 to +1.4% (from +8% to +10% before). With a default
> configuration, the numbers are closer to 0.8%.
Wow, an empty fentry function not "nop"ed out only add
On Thu, 24 Aug 2017, Rajiv Ranganath wrote:
> On Thu, Aug 24 2017 at 05:54:05 AM, Stefano Stabellini
> wrote:
> > On Mon, 21 Aug 2017, Rajiv Ranganath wrote:
> >> From: Rajiv M Ranganath
> >
> > Does .circleci need to be in the top directory or could it be under
> > fedora? If possible, I think
flight 112856 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112856/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
build-arm64-libvirt 1 build-check(1)
This run is configured for baseline tests only.
flight 72014 xen-4.7-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72014/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) b
On Thu, Aug 24, 2017 at 2:13 PM, Thomas Garnier wrote:
>
> My original performance testing was done with an Ubuntu generic
> configuration. This configuration has the CONFIG_FUNCTION_TRACER
> option which was incompatible with PIE. The tracer failed to replace
> the __fentry__ call by a nop slide
On 8/23/2017 5:20 PM, Konrad Rzeszutek Wilk wrote:
..snip..
Acked-by: Roger Pau Monné
Forgot to add, this needs to be backported to stable branches, so:
Annie, could you resend the patch with the tags and an update
to the description to me please?
Done
Thanks
Annie
Cc: sta...@vger.kernel.
In xen_blkif_disconnect, before checking inflight I/O, following code
stops the blkback thread,
if (ring->xenblkd) {
kthread_stop(ring->xenblkd);
wake_up(&ring->shutdown_wq);
}
If there is inflight I/O in any non-last queue, blkback returns -EBUSY
directly, and above code would not
On Thu, Aug 17, 2017 at 7:10 AM, Thomas Garnier wrote:
>
> On Thu, Aug 17, 2017 at 1:09 AM, Ingo Molnar wrote:
> >
> >
> > * Thomas Garnier wrote:
> >
> > > > > -model=small/medium assume you are on the low 32-bit. It generates
> > > > > instructions where the virtual addresses have the high 32-
On Thu, Aug 24, 2017 at 9:39 AM, Christoph Hellwig wrote:
> On Thu, Aug 24, 2017 at 09:31:17AM -0700, Dan Williams wrote:
>> External agent is a DMA device, or a hypervisor like Xen. In the DMA
>> case perhaps we can use the fcntl lease mechanism, I'll investigate.
>> In the Xen case it actually w
On 8/18/17 4:50 PM, Dario Faggioli wrote:
@@ -474,6 +586,12 @@ static inline struct csched2_runqueue_data *c2rqd(const struct scheduler *ops,
return &csched2_priv(ops)->rqd[c2r(cpu)];
}
+/* Does the domain of this vCPU have a cap? */
+static inline bool has_cap(const struct csche
On Thu, Aug 24, 2017 at 9:24 AM, Jan Beulich wrote:
On 24.08.17 at 17:17, wrote:
>> On Jo, 2017-08-24 at 07:24 -0600, Jan Beulich wrote:
>>> > @@ -500,6 +519,9 @@ bool_t vm_event_check_ring(struct
>>> > vm_event_domain *ved)
>>> > int __vm_event_claim_slot(struct domain *d, struct vm_event_
On Thu, Aug 24, 2017 at 5:48 AM, Alexandru Isaila
wrote:
> The patch splits the vm_event into three structures:vm_event_share,
> vm_event_paging, vm_event_monitor. The allocation for the
> structure is moved to vm_event_enable so that it can be
> allocated/init when needed and freed in vm_event_di
This run is configured for baseline tests only.
flight 72013 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72013/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 7 xen-boot
It is redundant with the *page parameter.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
---
xen/common/grant_table.c | 50 +---
1 file changed, 22 in
It is redundant with *page.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
---
xen/common/grant_table.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/xen/common/
Andrew Cooper (3):
gnttab: Drop the frame parameter from acquire_grant_for_copy()
gnttab: Drop the frame parameter from get_paged_frame()
gnttab: Drop the frame field from struct gnttab_copy_buf
xen/common/grant_table.c | 80 ++--
1 file changed,
It is redundant with the *page parameter. Rename the grant_frame parameter to
indicate that it is local, and highlight the correctness of the change.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Li
On 24/08/17 18:45, Juergen Gross wrote:
> On 24/08/17 17:16, Andrew Cooper wrote:
>> On 24/08/17 16:01, Juergen Gross wrote:
>>> On 24/08/17 16:50, Andrew Cooper wrote:
This patch was originally a workaround for XSA-226. Since then, transitive
grants are believed to be functioning proper
flight 112850 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112850/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
112820
Regressi
On 24/08/17 17:16, Andrew Cooper wrote:
> On 24/08/17 16:01, Juergen Gross wrote:
>> On 24/08/17 16:50, Andrew Cooper wrote:
>>> This patch was originally a workaround for XSA-226. Since then, transitive
>>> grants are believed to be functioning properly, and the defaults have
>>> changed
>>> app
On 21/08/17 21:27, Volodymyr Babchuk wrote:
This feature indicates that hypervisor is compatible with ARM
SMC calling convention. Hypervisor will not inject an undefined
instruction exception if an invalid SMC function were called and
will not crash a domain if an invlalid HVC functions were ca
On 22/08/17 08:29, Jan Beulich wrote:
On 21.08.17 at 22:27, wrote:
As Xen now supports SMCCC, we can enable this feature to tell
guests that it is safe to call generic SMCs and HVCs.
I think this and patch 10 should be folded.
+1.
Signed-off-by: Volodymyr Babchuk
---
xen/common/kern
Hi Volodymyr,
On 21/08/17 21:27, Volodymyr Babchuk wrote:
smccc.h provides definitions to construct SMC call function number according
to SMCCC. We don't need multiple definitions for one thing, and definitions
in smccc.h are more generic than ones used in psci.h.
So psci.h will only provide fu
flight 112861 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112861/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64-pvops 2 hos
On Tue, Aug 22, 2017 at 03:51:05PM +0100, Paul Durrant wrote:
> A subsequent patch will introduce a new scheme to allow an emulator to
> map IOREQ server pages directly from Xen rather than the guest P2M.
>
> This patch lays the groundwork for that change by deferring mapping of
> gfns until their
On Tue, Aug 22, 2017 at 03:51:04PM +0100, Paul Durrant wrote:
> This patch adjusts the IOREQ server code to use type-safe gfn_t values
> where possible. No functional change.
Oh, forget my comment on the previous patch then.
Thanks.
> Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
On Tue, Aug 22, 2017 at 03:51:03PM +0100, Paul Durrant wrote:
> This patch re-works much of the IOREQ server initialization and teardown
> code:
>
> - The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
> to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
>
Hi Volodymyr,
On 21/08/17 21:27, Volodymyr Babchuk wrote:
PSCI is part of HVC/SMC interface, so it should be handled in
appropriate place: `vsmc.c`. This patch just moves PSCI
handler calls from `traps.c` to `vsmc.c`.
Older PSCI 0.1 uses SMC function identifiers in range that is
resereved for e
Hi Volodymyr,
On 21/08/17 21:27, Volodymyr Babchuk wrote:
SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs.
SMCCC states that both HVC and SMC are valid conduits to call to different
firmware functions. Thus, for example, PSCI calls can be made both by
SMC or HVC. Also SMCC
On Thu, Aug 24, 2017 at 09:31:17AM -0700, Dan Williams wrote:
> External agent is a DMA device, or a hypervisor like Xen. In the DMA
> case perhaps we can use the fcntl lease mechanism, I'll investigate.
> In the Xen case it actually would need to use fiemap() to discover the
> physical addresses t
On Tue, Aug 22, 2017 at 03:50:56PM +0100, Paul Durrant wrote:
> In the case where a PV domain is mapping guest resources then it needs make
> the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest
> domid, so that the passed in gmfn values are correctly treated as mfns
> rather than
> -Original Message-
> From: Roger Pau Monne
> Sent: 24 August 2017 17:22
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Andrew Cooper
> ; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v2 REPOST 08/12] x86/hvm/ioreq: move
> is_default into struct hvm_ioreq_server
>
> On Tue, Au
[ adding Xen ]
On Thu, Aug 24, 2017 at 9:11 AM, Christoph Hellwig wrote:
> I still can't make any sense of this description. What is an external
> agent? Userspace obviously can't ever see a change in the extent
> map, so it can't be meant.
External agent is a DMA device, or a hypervisor like
On 24/08/17 17:33, Jan Beulich wrote:
On 23.08.17 at 19:33, wrote:
>> @@ -163,20 +163,24 @@ void __init cmdline_parse(const char *cmdline)
>> #endif
>> }
>>
>> -int __init parse_bool(const char *s)
>> +int __init parse_bool(const char *s, const char *e)
>> {
>> -if ( !strcmp("no", s)
On 24/08/17 17:35, Jan Beulich wrote:
On 23.08.17 at 19:34, wrote:
>> --- a/xen/arch/x86/psr.c
>> +++ b/xen/arch/x86/psr.c
>> @@ -418,50 +418,66 @@ static const struct feat_props l2_cat_props = {
>> .write_msr = l2_cat_write_msr,
>> };
>>
>> -static void __init parse_psr_bool(char *s,
On Tue, Aug 22, 2017 at 03:51:02PM +0100, Paul Durrant wrote:
> Legacy emulators use the 'default' IOREQ server which has slightly
> different semantics than other, explicitly created, IOREQ servers.
>
> Because of this, most of the initialization and teardown code needs to
> know whether the serv
On Tue, Aug 22, 2017 at 03:51:01PM +0100, Paul Durrant wrote:
> This patch changes use of bool_t to bool in the IOREQ server code. It also
> fixes an incorrect indentation in a continuation line.
>
> This patch is purely cosmetic. No semantic or functional change.
>
> Signed-off-by: Paul Durrant
Hello,
I was expecting to be CCed on this patch.
On 21/08/17 19:05, Juergen Gross wrote:
The x86 and arm versions of XENMAPSPACE_grant_table handling are nearly
identical. Move the code into a function in grant_table.c and add an
architecture dependant hook to handle the differences.
This at o
> -Original Message-
> From: Roger Pau Monne
> Sent: 24 August 2017 17:03
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Wei Liu ; Ian
> Jackson
> Subject: Re: [Xen-devel] [PATCH v2 REPOST 05/12] tools/libxenctrl: use new
> xenforeignmemory API to seed grant table
>
> On Tue, A
On Tue, Aug 22, 2017 at 03:51:00PM +0100, Paul Durrant wrote:
> Since IOREQ servers are only relevant to HVM guests and all the names in
> question unequivocally refer to guest frame numbers, name them all .*gfn
> to avoid any confusion.
>
> This patch is purely cosmetic. No semantic or functional
On Thu, Aug 24, 2017 at 05:27:21PM +0200, Vitaly Kuznetsov wrote:
> Do you think adding something like
>
> /*
> * While x86 architecture in general requires an IPI to perform TLB
> * shootdown, enablement code for several hypervisors overrides
> * .flush_tlb_others hook in pv_mmu_ops and implem
On Tue, Aug 22, 2017 at 03:50:59PM +0100, Paul Durrant wrote:
> A previous patch added support for priv-mapping guest resources directly
> (rather than having to foreign-map, which requires P2M modification for
> HVM guests).
>
> This patch makes use of the new API to seed the guest grant table un
> -Original Message-
> From: Roger Pau Monne
> Sent: 24 August 2017 16:53
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Wei Liu ; Ian
> Jackson
> Subject: Re: [Xen-devel] [PATCH v2 REPOST 04/12]
> tools/libxenforeignmemory: add support for resource mapping
>
> On Tue, Aug 22,
On Tue, Aug 22, 2017 at 03:50:58PM +0100, Paul Durrant wrote:
> diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h
> b/tools/libs/foreignmemory/include/xenforeignmemory.h
> index f4814c390f..e56eb3c4d4 100644
> --- a/tools/libs/foreignmemory/include/xenforeignmemory.h
> +++ b/tools/l
>>> On 14.08.17 at 16:28, wrote:
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -256,6 +256,25 @@ void register_g2m_portio_handler(struct domain *d)
> handler->ops = &g2m_portio_ops;
> }
>
> +unsigned int hvm_pci_decode_addr(unsigned int cf8, unsigned int addr,
> +
On 23/08/17 18:33, Juergen Gross wrote:
> Add a parameter to parse_bool() to specify the end of the to be
> parsed string. Specifying it as NULL will preserve the current
> behavior to parse until the end of the input string, while passing
> a non-NULL pointer will specify the first character after
>>> On 23.08.17 at 19:34, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -418,50 +418,66 @@ static const struct feat_props l2_cat_props = {
> .write_msr = l2_cat_write_msr,
> };
>
> -static void __init parse_psr_bool(char *s, char *value, char *feature,
> +static bool __
>>> On 23.08.17 at 19:33, wrote:
> @@ -163,20 +163,24 @@ void __init cmdline_parse(const char *cmdline)
> #endif
> }
>
> -int __init parse_bool(const char *s)
> +int __init parse_bool(const char *s, const char *e)
> {
> -if ( !strcmp("no", s) ||
> - !strcmp("off", s) ||
> -
>>> On 24.08.17 at 17:07, wrote:
> The flag is part of the gflags, and should be used to request the
> unmask of a MSI interrupt once it's bound.
>
> This is required for the device model in order to be capable of
> binding MSIX interrupts that have the entry mask bit already unset at
> bind time
Peter Zijlstra writes:
> On Thu, Aug 24, 2017 at 11:22:58AM +0200, Vitaly Kuznetsov wrote:
>
>> diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h
>> index c7797307fc2b..d43a7fcafee9 100644
>> --- a/arch/x86/include/asm/tlb.h
>> +++ b/arch/x86/include/asm/tlb.h
>> @@ -15,4 +15,9
On 24/08/17 16:16, Jan Beulich wrote:
On 17.08.17 at 16:44, wrote:
>> Move the code to pv/emul-mmio-op.c. Fix coding style issues while
>> moving.
>>
>> Note that mmio_ro_emulated_write is needed by both PV and HVM, so it
>> is left in x86/mm.c.
>>
>> Signed-off-by: Wei Liu
>> ---
>> xen/ar
>>> On 24.08.17 at 17:17, wrote:
> On Jo, 2017-08-24 at 07:24 -0600, Jan Beulich wrote:
>> > @@ -500,6 +519,9 @@ bool_t vm_event_check_ring(struct
>> > vm_event_domain *ved)
>> > int __vm_event_claim_slot(struct domain *d, struct vm_event_domain
>> > *ved,
>> >bool_t a
>>> On 24.08.17 at 17:13, wrote:
> On 24/08/17 17:04, Jan Beulich wrote:
> On 24.08.17 at 16:48, wrote:
>>> How would the guest know whether using v2 grants is no disadvantage?
>>
>> As said - it's always going to be a disadvantage. Even if controlling
>> the number of frames per-domain, tha
On 24/08/17 16:01, Juergen Gross wrote:
> On 24/08/17 16:50, Andrew Cooper wrote:
>> This patch was originally a workaround for XSA-226. Since then, transitive
>> grants are believed to be functioning properly, and the defaults have changed
>> appropriately.
>>
>> However, for those people who cho
On Jo, 2017-08-24 at 07:24 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 24.08.17 at 13:48, wrote:
> > The patch splits the vm_event into three structures:vm_event_share,
> > vm_event_paging, vm_event_monitor. The allocation for the
> > structure is moved to vm_event_enable so that it
>>> On 17.08.17 at 16:44, wrote:
> Move the code to pv/emul-mmio-op.c. Fix coding style issues while
> moving.
>
> Note that mmio_ro_emulated_write is needed by both PV and HVM, so it
> is left in x86/mm.c.
>
> Signed-off-by: Wei Liu
> ---
> xen/arch/x86/mm.c | 129 ---
>>> On 17.08.17 at 16:44, wrote:
> Move the code to pv/emul-ptwr-op.c. Fix coding style issues while
> moving the code.
>
> Rename ptwr_emulated_read to pv_emul_ptwr_read and export it via
> pv/mm.h because it is needed by other emulation code.
If other emulated code uses it, renaming the functi
On 24/08/17 17:01, Jan Beulich wrote:
On 24.08.17 at 16:54, wrote:
>> OTOH I think there should be a default especially on huge hosts
>> allowing to use v2 grants without reducing the number of allowed
>> grants, which doesn't need adding another parameter to the domain
>> config. Or do you w
On 24/08/17 17:04, Jan Beulich wrote:
On 24.08.17 at 16:48, wrote:
>> On 24/08/17 16:28, Jan Beulich wrote:
>> On 21.08.17 at 20:05, wrote:
Today a guest can get the maximum grant table frame number for the
currently selected grant table interface version (1 or 2) only. Add
>>>
Hello,
The following two patches fix an issue where a MSIX interrupt bound to
a guest when the MSIX entry is already unmasked would be left masked,
and thus the guest would not receive any interrupts from the device.
This is fixed by adding a new flag to the gflags field used in
XEN_DOMCTL_bind_p
The flag is part of the gflags, and should be used to request the
unmask of a MSI interrupt once it's bound.
This is required for the device model in order to be capable of
binding MSIX interrupts that have the entry mask bit already unset at
bind time. Without this fix the interrupts would be lef
When a MSI interrupt is bound to a guest using
xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
left masked by default.
This causes problems with guests that first configure interrupts and
clean the per-entry MSIX table mask bit and afterwards enable MSIX
globally. In such scenar
>>> On 24.08.17 at 16:48, wrote:
> On 24/08/17 16:28, Jan Beulich wrote:
> On 21.08.17 at 20:05, wrote:
>>> Today a guest can get the maximum grant table frame number for the
>>> currently selected grant table interface version (1 or 2) only. Add
>>> a new grant table operation to get the lim
On 24/08/17 16:48, Juergen Gross wrote:
> On 24/08/17 16:28, Jan Beulich wrote:
> On 21.08.17 at 20:05, wrote:
>>> Today a guest can get the maximum grant table frame number for the
>>> currently selected grant table interface version (1 or 2) only. Add
>>> a new grant table operation to get t
>>> On 24.08.17 at 16:54, wrote:
> OTOH I think there should be a default especially on huge hosts
> allowing to use v2 grants without reducing the number of allowed
> grants, which doesn't need adding another parameter to the domain
> config. Or do you want the tools to always set the per-domain
On 24/08/17 16:50, Andrew Cooper wrote:
> This patch was originally a workaround for XSA-226. Since then, transitive
> grants are believed to be functioning properly, and the defaults have changed
> appropriately.
>
> However, for those people who chose to use the workaround (especially from an
>
Hi Volodymyr,
Title: No need for the full stop.
On 21/08/17 21:27, Volodymyr Babchuk wrote:
This patch adds generic definitions used in ARM SMC call convention.
Those definitions was taken from linux header arm-smccc.h, extended
and formatted according to XEN coding style.
They can be used by
>>> On 17.08.17 at 16:44, wrote:
> Those macros will soon be used in different files. They are PV
> specific so move them to pv/mm.h.
Same comment here regarding where to move them.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists
>>> On 17.08.17 at 16:44, wrote:
> That function is only used by PV guests supporting code, add pv_
> prefix.
Is any code outside of x86/pv/ going to need access to it? I hope not,
in which case it shouldn't be exposed via include/asm-x86/pv/mm.h,
but via a private header in x86/pv/. That non-pri
>>> On 17.08.17 at 16:44, wrote:
> It will be used by different files later, so export it via
> asm-x86/mm.h.
This is a pretty thin wrapper - wouldn't be better to make it a
static inline?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https:
On 24/08/17 16:21, Jan Beulich wrote:
On 21.08.17 at 20:05, wrote:
>> The number of grants a domain can setup is limited by the maximum
>> number of grant frames it is allowed to use. Today the limit is the
>> same regardless whether the domain uses grant v1 or v2. Using v2
>> will therefor b
>>> On 17.08.17 at 16:44, wrote:
> Move them to pv/mm.c and rename them to pv_get_guest_eff_{,kern}_l1e.
> Export them via pv/mm.h.
I think these should remain static inlines. If either is really needed by
more than one C file, it may be best to move it/them to a private
header in x86/pv/. But gu
This patch was originally a workaround for XSA-226. Since then, transitive
grants are believed to be functioning properly, and the defaults have changed
appropriately.
However, for those people who chose to use the workaround (especially from an
attack surface mitigation point of view), retain th
On 24/08/17 16:28, Jan Beulich wrote:
On 21.08.17 at 20:05, wrote:
>> Today a guest can get the maximum grant table frame number for the
>> currently selected grant table interface version (1 or 2) only. Add
>> a new grant table operation to get the limits of both variants in
>> order to give
Hi Volodymyr,
Title: It is a too generic, you may want to rename to: "Define HVC/SMC
immediate mask"
On 21/08/17 21:27, Volodymyr Babchuk wrote:
This patch adds definition HSR_XXC_IMM_MASK. It can be used to extract
s/adds definition/define/
immediate value for trapped HVC32, HVC64, SMC64
Hi Volodymyr,
On 21/08/17 21:27, Volodymyr Babchuk wrote:
Trapped SMC instruction can fail condition check on ARMv8 arhcitecture
s/arhcitecture/architecture/
(ARM DDI 0487B.a page D7-2271). So we need to check if condition was meet.
Signed-off-by: Volodymyr Babchuk
Reviewed-by: Julien Gr
On Thu, Aug 24, 2017 at 07:09:08AM -0600, Jan Beulich wrote:
> >>> On 24.08.17 at 14:19, wrote:
> > When a MSI interrupt is bound to a guest using
> > xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
> > left masked by default.
> >
> > This causes problems with guests that first
Hi Volodymyr,
On 21/08/17 21:27, Volodymyr Babchuk wrote:
There are standard functions set_user_reg() and get_user_reg(). We can
use them in PSCI_SET_RESULT()/PSCI_ARG() macroses instead of relying on
s/macroses/macros/ I think.
CONFIG_ARM_64 definition.
Signed-off-by: Volodymyr Babchuk
--
On Thu, Aug 24, 2017 at 11:22:58AM +0200, Vitaly Kuznetsov wrote:
> diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h
> index c7797307fc2b..d43a7fcafee9 100644
> --- a/arch/x86/include/asm/tlb.h
> +++ b/arch/x86/include/asm/tlb.h
> @@ -15,4 +15,9 @@
>
> #include
>
> +stati
On 08/24/2017 08:39 AM, Jan Beulich wrote:
On 24.08.17 at 13:33, wrote:
Hi Jan,
2017-08-24 14:37 GMT+08:00 Jan Beulich :
On 24.08.17 at 02:51, wrote:
2017-08-23 17:55 GMT+08:00 Jan Beulich :
On 22.08.17 at 20:08, wrote:
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -525,
On Wed, Aug 23, 2017 at 07:34:42PM +0200, Juergen Gross wrote:
> Add a sysctl hypercall to support setting parameters similar to
> command line parameters, but at runtime. The parameters to set are
> specified as a string, just like the boot parameters.
>
> Cc: Daniel De Graaf
> Cc: Ian Jackson
On 24/08/17 16:17, Jan Beulich wrote:
On 21.08.17 at 20:05, wrote:
>> @@ -118,6 +154,18 @@ struct grant_mapping {
>> uint32_t pad; /* round size to a power of 2 */
>> };
>>
>> +/* Number of grant table frames. Caller must hold d's grant table lock. */
>> +static inline unsig
>>> On 21.08.17 at 20:05, wrote:
> Today a guest can get the maximum grant table frame number for the
> currently selected grant table interface version (1 or 2) only. Add
> a new grant table operation to get the limits of both variants in
> order to give the guest an opportunity to select the ver
On Wed, Aug 23, 2017 at 07:34:33PM +0200, Juergen Gross wrote:
> Where possible check validity of parameters in _cmdline_parse() and
> issue a warning message in case of an error detected.
>
> In order to make sure a custom parameter parsing function really
> returns a value (error or success), do
On Thu, Aug 24, 2017 at 03:03:49PM +0100, Julien Grall wrote:
> Hi,
>
> On 23/08/17 15:05, Roger Pau Monné wrote:
> > On Wed, Aug 23, 2017 at 11:19:01AM +0100, Julien Grall wrote:
> > > Hi Roger,
> > >
> > > On 23/08/17 08:22, Roger Pau Monné wrote:
> > > > On Wed, Aug 23, 2017 at 02:06:17PM +080
flight 112851 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112851/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 112793
Tests which did not succ
1 - 100 of 200 matches
Mail list logo
