On Tue, Apr 18, 2017 at 02:24:05PM +0800, Tian, Kevin wrote:
>> From: Gao, Chao
>> Sent: Monday, April 17, 2017 4:14 AM
>>
>> On Tue, Apr 11, 2017 at 02:21:07AM -0600, Jan Beulich wrote:
>> On 11.04.17 at 02:59, wrote:
>> 3. Like what we do in struct irq_guest_action_t, can we limit the
>> m
On Mon, Apr 17, 2017 at 05:09:22PM +0100, Roger Pau Monne wrote:
> The current vIO APIC for PVH Dom0 doesn't allow non-contiguous GSIs, which
> means that all GSIs must belong to an IO APIC. This doesn't match reality,
> where there are systems with non-contiguous GSIs.
>
> In order to fix this ad
Hi Konrad:
Thanks for your review.
On 2017年04月17日 22:36, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 17, 2017 at 07:27:02PM +0800, Lan Tianyu wrote:
>> This patch is to introduce create, destroy and query capabilities
>> command for vIOMMU. vIOMMU layer will deal with requests and call
>> a
On Tue, Apr 18, 2017 at 03:04:51AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné [mailto:roger@citrix.com]
> > Sent: Friday, April 14, 2017 11:35 PM
> >
> > Hello,
> >
> > Although PVHv2 Dom0 is not yet finished, I've been trying the current code
> > on
> > different hardware, and found
Hello,
Please include all the relevant maintainers for the code you modified.
On 06/04/2017 20:47, Chris Patterson wrote:
From: Chris Patterson
Tegra boards feature a NS16550-compatible serial mapped into the MMIO
space. Add support for its use both as a full-featured serial port and
as an ea
Hello Chris,
On 17/04/2017 16:03, Chris Patterson wrote:
+static const char * const tegra_dt_compat[] __initconst =
+{
+"nvidia,tegra120", /* Tegra K1 */
This is still tegra120 (not tegra124), is that intended? If so, it is
still missing from arch/arm*/boot/dts. Do you have a pointer?
I
Hello,
On 06/04/2017 20:47, Chris Patterson wrote:
From: "Chris Patterson"
Currently, the interrupt parent is left undefined during creation in
make_gic_node(). In cases where a non-GIC interrupt controller is present,
this can lead to incorrect assignment of interrupt parents.
On the Tegra,
On 13/04/17 19:57, Stefano Stabellini wrote:
> In order to use "len" to check for xenbus_read errors properly, we need
> to initialize len to 0 before passing it to xenbus_read.
>
> Signed-off-by: Stefano Stabellini
> CC: dan.carpen...@oracle.com
> CC: jgr...@suse.com
> CC: boris.ostrov...@oracle
>>> On 16.04.17 at 22:13, wrote:
> 3. Like what we do in struct irq_guest_action_t, can we limit the
> maximum of entry we support in the list. With this approach, during
> domain creation, we calculate the available entries and compare with
> the domain's vCPU number to decide whether the domain
Hello,
On 06/04/2017 20:47, Chris Patterson wrote:
From: "Chris Patterson"
Tegra devices have a legacy interrupt controller (lic, or ictlr) that
must be programmed in parallel with their primary GIC. For all intents
and purposes, we treat these devices attached to this controller as
connected
Hello,
On 06/04/2017 20:47, Chris Patterson wrote:
From: "Chris Patterson"
The addition of new IRQ-related platform hooks now allow platforms to
perform platform-specific interrupt logic, such as allowing virtualization
of platform-specific interrupt controller hardware.
This commit adds the
On 2017年04月17日 22:39, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 17, 2017 at 07:27:03PM +0800, Lan Tianyu wrote:
>> This patch is to add irq request callback for platform implementation
>> to deal with irq remapping request.
>>
>> Signed-off-by: Lan Tianyu
>> ---
>> xen/common/viommu.c |
On 2017年04月17日 22:41, Konrad Rzeszutek Wilk wrote:
> On Mon, Mar 20, 2017 at 02:23:02PM +, Roger Pau Monné wrote:
>> On Fri, Mar 17, 2017 at 07:27:00PM +0800, Lan Tianyu wrote:
>>> This patchset is to introduce vIOMMU framework and add virtual VTD's
>>> interrupt remapping support according "Xe
On 12/04/17 00:45, Glenn Enright wrote:
> On 12/04/17 10:23, Andrew Cooper wrote:
>> On 11/04/2017 23:13, Glenn Enright wrote:
>>> On 11/04/17 21:49, Dietmar Hahn wrote:
Am Dienstag, 11. April 2017, 20:03:14 schrieb Glenn Enright:
> On 11/04/17 17:59, Juergen Gross wrote:
>> On 11/04/1
>>> On 17.04.17 at 18:09, wrote:
> @@ -601,7 +587,12 @@ int vioapic_init(struct domain *d)
> nr_gsis += nr_pins;
> }
>
> -ASSERT(hvm_domain_irq(d)->nr_gsis == nr_gsis);
> +/*
> + * NB: hvm_domain_irq(d)->nr_gsis is actually the highest GSI + 1, but
> + * there might
Hello,
On 06/04/2017 20:47, Chris Patterson wrote:
From: Chris Patterson
Several Tegra hardware devices, and the Tegra device tree, expect
the presence of a Tegra Legacy Interrupt Controller (LIC) in the hardware
domain. Accordingly, we'll need to expose (most of) the LIC's registers
to the ha
On 2017年04月17日 22:43, Konrad Rzeszutek Wilk wrote:
> On Fri, Mar 17, 2017 at 07:27:15PM +0800, Lan Tianyu wrote:
>> From: Chao Gao
>>
>> When irq remapping enabled, IOAPIC Redirection Entry maybe is in remapping
>> format. If that, generate a irq_remapping_request and send it to domain.
>>
>> Sign
>>> On 18.04.17 at 09:34, wrote:
> (XEN) Before DMA_GCMD_TE
> (
>
> The hang seems to happen when writing DMA_GCMD_TE to the global command
> register, which enables the DMA remapping. After that the box is completely
> unresponsive, not even the watchdog is working.
How sure are you that this i
On Tue, Apr 18, 2017 at 02:39:34AM -0600, Jan Beulich wrote:
> >>> On 17.04.17 at 18:09, wrote:
> > @@ -601,7 +587,12 @@ int vioapic_init(struct domain *d)
> > nr_gsis += nr_pins;
> > }
> >
> > -ASSERT(hvm_domain_irq(d)->nr_gsis == nr_gsis);
> > +/*
> > + * NB: hvm_doma
On 18/04/2017 09:49, Roger Pau Monne wrote:
> On Tue, Apr 18, 2017 at 02:39:34AM -0600, Jan Beulich wrote:
> On 17.04.17 at 18:09, wrote:
>>> @@ -601,7 +587,12 @@ int vioapic_init(struct domain *d)
>>> nr_gsis += nr_pins;
>>> }
>>>
>>> -ASSERT(hvm_domain_irq(d)->nr_gsis ==
>>> On 13.04.17 at 18:00, wrote:
> On 13/04/17 16:28, Jan Beulich wrote:
> On 13.04.17 at 16:59, wrote:
>>> On 13/04/17 15:51, Jan Beulich wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3598,6 +3598,28 @@ gp_fault:
return X86EMUL_EXCEPTION;
On Tue, Apr 18, 2017 at 02:48:31AM -0600, Jan Beulich wrote:
> >>> On 18.04.17 at 09:34, wrote:
> > (XEN) Before DMA_GCMD_TE
> > (
> >
> > The hang seems to happen when writing DMA_GCMD_TE to the global command
> > register, which enables the DMA remapping. After that the box is completely
> > un
>>> On 18.04.17 at 10:49, wrote:
> On Tue, Apr 18, 2017 at 02:39:34AM -0600, Jan Beulich wrote:
>> >>> On 17.04.17 at 18:09, wrote:
>> > @@ -601,7 +587,12 @@ int vioapic_init(struct domain *d)
>> > nr_gsis += nr_pins;
>> > }
>> >
>> > -ASSERT(hvm_domain_irq(d)->nr_gsis == nr_g
> -Original Message-
> From: Lan, Tianyu [mailto:tianyu@intel.com]
> Sent: 14 April 2017 16:38
> To: Paul Durrant ; Wei Liu ;
> Kevin Tian ; Ian Jackson ;
> xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc: Add viommu
> operations in libxc
>
> Hi Paul:
>
The current vIO APIC for PVH Dom0 doesn't allow non-contiguous GSIs, which
means that all GSIs must belong to an IO APIC. This doesn't match reality,
where there are systems with non-contiguous GSIs.
In order to fix this add a base_gsi field to each hvm_vioapic struct, in order
to store the base G
Hi,
On 13/04/2017 18:18, Andrew Cooper wrote:
On 13/04/17 07:07, Jan Beulich wrote:
No matter that we emulate IRET for (guest) real more only right now, we
should get its effect on (virtual) NMI delivery right. Note that we can
simply check the other retire flags also in the !OKAY case, as the
>>> On 18.04.17 at 11:14, wrote:
> @@ -554,6 +539,7 @@ void vioapic_reset(struct domain *d)
> {
> vioapic->base_address = mp_ioapics[i].mpc_apicaddr;
> vioapic->id = mp_ioapics[i].mpc_apicid;
> +vioapic->base_gsi = io_apic_gsi_base(i);
The value does
> On 14. Apr 2017, at 11:20, Wei Liu wrote:
>
> Unfortunately there is an easy way to determine system name in the standard
> library so I wrote a wrapper for uname syscall.
I think there are two solutions to using the correct path:
(1) Determine the path at compile time and use the mechanism
On Tue, Apr 11, Jan Beulich wrote:
> I'm afraid successful testing is not a sufficient criteria here. At
> the very least the (so far missing) documentation needs to very
> clearly point out the possible risks associated with using this
> option. But with there not being any functional change when
On Tue, Apr 18, 2017 at 10:46:15AM +0100, Christian Lindig wrote:
>
> > On 14. Apr 2017, at 11:20, Wei Liu wrote:
> >
> > Unfortunately there is an easy way to determine system name in the standard
> > library so I wrote a wrapper for uname syscall.
>
> I think there are two solutions to using
> -Original Message-
> From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> Sent: 15 April 2017 01:40
> To: Stefano Stabellini
> Cc: Paul Durrant ; qemu-de...@nongnu.org;
> Anthony Perard ; Wei Liu
> ; jgr...@suse.com; julien.gr...@arm.com; xen-
> de...@lists.xenproject.org
> Subject
flight 71200 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71200/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-weekly-netinst-pygrub 6 xen-boot fail REGR. vs. 71171
test-
On 18/04/17 07:31, Juergen Gross wrote:
> @@ -281,22 +274,24 @@ static bool __init xen_check_mwait(void)
> return false;
> #endif
> }
> -static void __init xen_init_cpuid_mask(void)
> +
> +static bool __init xen_check_xsave(void)
> {
> - unsigned int ax, bx, cx, dx;
> - unsigned in
On Mon, Apr 17, 2017 at 02:33:10PM -0700, Alistair Francis wrote:
> The POSIX spec specifies to use:
> #include
> instead of:
> #include
> as seen here:
> http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html
>
> This removes the warning:
> #warning redirecting incor
On Mon, Apr 17, 2017 at 02:33:11PM -0700, Alistair Francis wrote:
> The POSIX spec specifies to use:
> #include
> instead of:
> #include
> as seen here:
>http://pubs.opengroup.org/onlinepubs/009695399/functions/signal.html
>
> This removes the warning:
> #warning redirecting inco
On 2017年04月18日 17:08, Paul Durrant wrote:
>> -Original Message-
>> From: Lan, Tianyu [mailto:tianyu@intel.com]
>> Sent: 14 April 2017 16:38
>> To: Paul Durrant ; Wei Liu ;
>> Kevin Tian ; Ian Jackson ;
>> xen-devel@lists.xen.org
>> Subject: Re: [Xen-devel] [RFC PATCH 5/23] Tools/libxc:
Cc Julien
I think these two patches should be in 4.9.
On Mon, Apr 17, 2017 at 02:33:10PM -0700, Alistair Francis wrote:
> The POSIX spec specifies to use:
> #include
> instead of:
> #include
> as seen here:
> http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html
>
> Th
> On 18. Apr 2017, at 10:59, Wei Liu wrote:
>
> Forgive my ignorance for the Ocaml ecosystem, but I can't seem to find a
> way to conditionally compile ocaml source code easily.
>
> Presumably you mean "Determine the path at *configure* time"? Even if
> we make those configurable, there should
> On 18. Apr 2017, at 10:59, Wei Liu wrote:
>
> Forgive my ignorance for the Ocaml ecosystem, but I can't seem to find a
> way to conditionally compile ocaml source code easily.
>
> Presumably you mean "Determine the path at *configure* time"? Even if
> we make those configurable, there should
Really CC Julien. :-/
On Tue, Apr 18, 2017 at 11:10:59AM +0100, Wei Liu wrote:
> Cc Julien
>
> I think these two patches should be in 4.9.
>
> On Mon, Apr 17, 2017 at 02:33:10PM -0700, Alistair Francis wrote:
> > The POSIX spec specifies to use:
> > #include
> > instead of:
> > #include
Wei Liu writes ("[PATCH for-4.9 1/2] oxenstored: add an Unix syscall C
extension"):
> Currently there is only uname syscall in it.
I agree that this would be good to have in 4.9. The ocaml FFI has
tricky memory management, so this needs review by an ocaml expert.
Ian.
_
On 04/18/2017 01:02 PM, Wei Liu wrote:
> On Mon, Apr 17, 2017 at 02:33:10PM -0700, Alistair Francis wrote:
>> The POSIX spec specifies to use:
>> #include
>> instead of:
>> #include
>> as seen here:
>> http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html
>>
>> This remov
Wei Liu writes ("[PATCH for-4.9] oxenstored: remove "_proc" in names"):
> They aren't limited to proc file system anymore. Use more generic names.
>
> No functional change.
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https
On 04/18/2017 01:03 PM, Wei Liu wrote:
> On Mon, Apr 17, 2017 at 02:33:11PM -0700, Alistair Francis wrote:
>> The POSIX spec specifies to use:
>> #include
>> instead of:
>> #include
>> as seen here:
>>http://pubs.opengroup.org/onlinepubs/009695399/functions/signal.html
>>
>> This remo
Wei Liu writes ("[PATCH for-4.9 2/2] oxenstored: make it work on FreeBSD"):
> Call the uname syscall to determine sysname and return device names
> accordingly.
...
> -let xenstored_proc_kva = "/proc/xen/xsd_kva"
> -let xenstored_proc_port = "/proc/xen/xsd_port"
> +let xenstored_proc_kva =
> + let
>>> On 18.04.17 at 11:50, wrote:
> On Tue, Apr 11, Jan Beulich wrote:
>
>> I'm afraid successful testing is not a sufficient criteria here. At
>> the very least the (so far missing) documentation needs to very
>> clearly point out the possible risks associated with using this
>> option. But with
> On 18. Apr 2017, at 11:16, Ian Jackson wrote:
>
> Wei Liu writes ("[PATCH for-4.9 2/2] oxenstored: make it work on FreeBSD"):
>> Call the uname syscall to determine sysname and return device names
>> accordingly.
> ...
>> -let xenstored_proc_kva = "/proc/xen/xsd_kva"
>> -let xenstored_proc_por
Patch 2 brings recently added code in line with what we did switch
other code to during this dev cycle. Patch 3 is at least a latent bug fix.
Patch 4 is merely improving debuggability, so other than the first two
I'm not sure it qualifies for 4.9.
This is all fallout from re-basing my UMIP emulati
The function is rather unlikely to be called for insns which don't have
ModRM bytes, and hence addressing Coverity's recurring complaint of
callers potentially consuming uninitialized data when they know that
certain opcodes have ModRM bytes can be suppressed this way without
unduly adding overhead
While I did review d0a699a389 ("x86/monitor: add support for descriptor
access events") it didn't really occur to me that someone could be this
blunt and add unguarded emulation again just a few weeks after we
guarded all special purpose emulator invocations. Fix this.
Signed-off-by: Jan Beulich
On 18/04/17 11:29, Jan Beulich wrote:
> The function is rather unlikely to be called for insns which don't have
> ModRM bytes, and hence addressing Coverity's recurring complaint of
> callers potentially consuming uninitialized data when they know that
> certain opcodes have ModRM bytes can be supp
This is an optional feature and hence we should check for it before
use.
Signed-off-by: Jan Beulich
---
v2: Re-do detection of availability, resulting in almost all of the
changes done here being different than in v1.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -22
This helps distinguishing the call paths leading there.
Signed-off-by: Jan Beulich
Reviewed-by: Boris Ostrovsky
Reviewed-by: Andrew Cooper
Reviewed-by: Kevin Tian
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2033,7 +2033,7 @@ int hvm_emulate_one_mmio(unsigned long m
On 18/04/17 11:31, Jan Beulich wrote:
> While I did review d0a699a389 ("x86/monitor: add support for descriptor
> access events") it didn't really occur to me that someone could be this
> blunt and add unguarded emulation again just a few weeks after we
> guarded all special purpose emulator invoca
On 04/18/2017 01:32 PM, Jan Beulich wrote:
> This is an optional feature and hence we should check for it before
> use.
>
> Signed-off-by: Jan Beulich
> ---
> v2: Re-do detection of availability, resulting in almost all of the
> changes done here being different than in v1.
Acked-by: Razvan
On Tue, Apr 18, 2017 at 02:13:36AM -0600, Jan Beulich wrote:
On 16.04.17 at 22:13, wrote:
>> 3. Like what we do in struct irq_guest_action_t, can we limit the
>> maximum of entry we support in the list. With this approach, during
>> domain creation, we calculate the available entries and comp
On 18/04/17 11:32, Jan Beulich wrote:
> This is an optional feature and hence we should check for it before
> use.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-d
>>> On 17.04.17 at 21:09, wrote:
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -50,9 +50,10 @@ static cpumask_t crash_saved_cpus;
>
> static struct kexec_image *kexec_image[KEXEC_IMAGE_NR];
>
> -#define KEXEC_FLAG_DEFAULT_POS (KEXEC_IMAGE_NR + 0)
> -#define KEXEC_FLAG_CRASH_POS
>>> On 17.04.17 at 21:09, wrote:
> The spinlock in kexec_swap_images() was removed as
> this function is only reachable on the kexec hypercall, which is
> now protected at the top-level in do_kexec_op_internal(),
> thus the local spinlock is no longer necessary.
But perhaps leave an ASSERT() ther
>>> On 18.04.17 at 05:41, wrote:
> On Tue, Apr 18, 2017 at 02:13:36AM -0600, Jan Beulich wrote:
> On 16.04.17 at 22:13, wrote:
>>> 3. Like what we do in struct irq_guest_action_t, can we limit the
>>> maximum of entry we support in the list. With this approach, during
>>> domain creation, we
flight 107489 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107489/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
flight 107492 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107492/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 51de5c302fed13b110963b3863fe69d6e2a51079
baseline version:
ovmf 51a1db9b24d850c785d24
On 17-04-13 05:50:01, Jan Beulich wrote:
> >>> On 13.04.17 at 13:44, wrote:
> > On 17-04-13 05:31:41, Jan Beulich wrote:
> >> >>> On 13.04.17 at 13:11, wrote:
> >> > On 17-04-13 04:58:06, Jan Beulich wrote:
> >> >> >>> On 13.04.17 at 12:49, wrote:
> >> >> > How about a per socket array like this
Hi Wei,
Release-acked-by: Julien Grall
Cheers,
On 18/04/17 11:13, Wei Liu wrote:
Really CC Julien. :-/
On Tue, Apr 18, 2017 at 11:10:59AM +0100, Wei Liu wrote:
Cc Julien
I think these two patches should be in 4.9.
On Mon, Apr 17, 2017 at 02:33:10PM -0700, Alistair Francis wrote:
The POSI
The current vIO APIC for PVH Dom0 doesn't allow non-contiguous GSIs, which
means that all GSIs must belong to an IO APIC. This doesn't match reality,
where there are systems with non-contiguous GSIs.
In order to fix this add a base_gsi field to each hvm_vioapic struct, in order
to store the base G
On Tue, Apr 18, 2017 at 01:16:04PM +0300, Razvan Cojocaru wrote:
> On 04/18/2017 01:03 PM, Wei Liu wrote:
> > On Mon, Apr 17, 2017 at 02:33:11PM -0700, Alistair Francis wrote:
> >> The POSIX spec specifies to use:
> >> #include
> >> instead of:
> >> #include
> >> as seen here:
> >>htt
> On 13 Apr 2017, at 14:56, Jason Long wrote:
>
> It is a good news and I hope Xen experts thinking about beginners like me.
> Xen is great but have some problems in documenting and easy to use. I hope to
> see this book on Xen Project website soon.
>
> Thank you Xen team.
You are welcome. T
>>> On 18.04.17 at 12:55, wrote:
> I made a test patch based on v10 and attached it in mail. Could you please
> help to check it? Thanks!
This looks reasonable at the first glance, albeit I continue to be
unconvinced that this is the only (reasonable) way of solving the
problem. After all we don'
>>> On 18.04.17 at 13:42, wrote:
> @@ -538,7 +523,8 @@ void vioapic_reset(struct domain *d)
> for ( i = 0; i < d->arch.hvm_domain.nr_vioapics; i++ )
> {
> struct hvm_vioapic *vioapic = domain_vioapic(d, i);
> -unsigned int pin, nr_pins = vioapic->nr_pins;
> +unsi
flight 107490 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107490/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail in 107481
pass in 107490
test-amd64-i386-r
On Tue, Apr 18, 2017 at 05:52:47AM -0600, Jan Beulich wrote:
> >>> On 18.04.17 at 13:42, wrote:
> > @@ -538,7 +523,8 @@ void vioapic_reset(struct domain *d)
> > for ( i = 0; i < d->arch.hvm_domain.nr_vioapics; i++ )
> > {
> > struct hvm_vioapic *vioapic = domain_vioapic(d, i);
>
On 18/04/17 12:02, Andrew Cooper wrote:
> On 18/04/17 07:31, Juergen Gross wrote:
>> @@ -281,22 +274,24 @@ static bool __init xen_check_mwait(void)
>> return false;
>> #endif
>> }
>> -static void __init xen_init_cpuid_mask(void)
>> +
>> +static bool __init xen_check_xsave(void)
>> {
>> -
>>> On 18.04.17 at 13:55, wrote:
> On Tue, Apr 18, 2017 at 05:52:47AM -0600, Jan Beulich wrote:
>> >>> On 18.04.17 at 13:42, wrote:
>> > @@ -538,7 +523,8 @@ void vioapic_reset(struct domain *d)
>> > for ( i = 0; i < d->arch.hvm_domain.nr_vioapics; i++ )
>> > {
>> > struct hvm_v
>>> On 27.03.17 at 12:44, wrote:
> --- a/xen/include/xen/hvm/irq.h
> +++ b/xen/include/xen/hvm/irq.h
> @@ -81,14 +81,16 @@ struct hvm_girq_dpci_mapping {
>
> /* Protected by domain's event_lock */
> struct hvm_irq_dpci {
> -/* Guest IRQ to guest device/intx mapping. */
> -struct list_h
>>> On 27.03.17 at 12:44, wrote:
> --- a/xen/arch/x86/io_apic.c
> +++ b/xen/arch/x86/io_apic.c
> @@ -2261,6 +2261,28 @@ int io_apic_set_pci_routing (int ioapic, int pin, int
> irq, int edge_level, int a
> return 0;
> }
>
> +unsigned int io_apic_get_gsi_trigger(unsigned int gsi)
bool
> +
>>> On 27.03.17 at 12:44, wrote:
> So they can be called outside of the physdev.c file.
But they aren't meant to be, which is the entire reason the
declarations aren't in a header. Hence the rationale needs to be
extended here.
Jan
___
Xen-devel mail
On 04/18/2017 02:49 AM, Jan Beulich wrote:
On 13.04.17 at 18:55, wrote:
>> On 04/13/2017 11:46 AM, Jan Beulich wrote:
>> On 03.04.17 at 18:50, wrote:
While waiting for a lock we may want to periodically run some
code. We could use spin_trylock() but since it doesn't take lock
>
>>> On 27.03.17 at 12:44, wrote:
> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -199,6 +199,34 @@ static void vioapic_write_redirent(
> unmasked = unmasked && !ent.fields.mask;
> }
>
> +if ( is_hardware_domain(d) && unmasked )
> +{
> +xen
On Tue, Apr 18, 2017 at 12:42:07PM +0100, Roger Pau Monne wrote:
>The current vIO APIC for PVH Dom0 doesn't allow non-contiguous GSIs, which
>means that all GSIs must belong to an IO APIC. This doesn't match reality,
>where there are systems with non-contiguous GSIs.
>
>In order to fix this add a b
>>> On 18.04.17 at 14:32, wrote:
> On 04/18/2017 02:49 AM, Jan Beulich wrote:
> On 13.04.17 at 18:55, wrote:
>>> On 04/13/2017 11:46 AM, Jan Beulich wrote:
>>> On 03.04.17 at 18:50, wrote:
> While waiting for a lock we may want to periodically run some
> code. We could use spin_t
On Tue, Apr 11, 2017 at 11:03:56AM +0100, Roger Pau Monne wrote:
> Hello,
>
> The following series contain an implementation of handlers for the PCI
> configuration space inside of Xen. This allows Xen to detect accesses to the
> PCI configuration space and react accordingly.
>
> I'm still not su
flight 107491 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107491/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 4 host-build-prep fail REGR. vs. 107358
test-armhf-armhf-xl-c
flight 107493 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107493/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 3 host-install(3)broken REGR. vs. 107442
test-armhf-armhf-libvir
On Tue, Apr 18, 2017 at 11:11:20AM +0100, Christian Lindig wrote:
>
> > On 18. Apr 2017, at 10:59, Wei Liu wrote:
> >
> > Forgive my ignorance for the Ocaml ecosystem, but I can't seem to find a
> > way to conditionally compile ocaml source code easily.
> >
> > Presumably you mean "Determine th
On 04/18/2017 08:43 AM, Jan Beulich wrote:
On 18.04.17 at 14:32, wrote:
>> On 04/18/2017 02:49 AM, Jan Beulich wrote:
>> On 13.04.17 at 18:55, wrote:
On 04/13/2017 11:46 AM, Jan Beulich wrote:
On 03.04.17 at 18:50, wrote:
>> While waiting for a lock we may want to peri
This run is configured for baseline tests only.
flight 71201 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71201/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 51de5c302fed13b110963b3863fe69d6e2a51079
baseline v
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 18 April 2017 11:34
> To: xen-devel
> Cc: Suravee Suthikulpanit ; Julien Grall
> ; Andrew Cooper ;
> Paul Durrant ; Jun Nakajima
> ; Kevin Tian ; Boris
> Ostrovsky
> Subject: [PATCH v2 4/4] x86/HVM: don't uniforml
Commit b988e88cc0 ("x86/emul: Add feature check for clzero") added a
feature check to the emulator, which breaks the harness without this
flag being forced to true.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/x86_emulate.c
+++ b/tools/tests/x86_emulator/x86_emulate.c
@@ -89,6 +89,1
On 18/04/17 14:16, Jan Beulich wrote:
> Commit b988e88cc0 ("x86/emul: Add feature check for clzero") added a
> feature check to the emulator, which breaks the harness without this
> flag being forced to true.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Alistair Francis writes ("[PATCH 2/2] tools: Use POSIX signal.h instead of
sys/signal.h"):
> The POSIX spec specifies to use:
> #include
> instead of:
> #include
> as seen here:
>http://pubs.opengroup.org/onlinepubs/009695399/functions/signal.html
Both:
Acked-by: Ian Jackson
Juli
On Tue, Apr 18, 2017 at 03:24:35PM +0800, Lan Tianyu wrote:
> Hi Konrad:
> Thanks for your review.
>
> On 2017年04月17日 22:36, Konrad Rzeszutek Wilk wrote:
> > On Fri, Mar 17, 2017 at 07:27:02PM +0800, Lan Tianyu wrote:
> >> This patch is to introduce create, destroy and query capabilities
> >
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, April 18, 2017 6:33 PM
>
> This is an optional feature and hence we should check for it before
> use.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Kevin Tian
___
Xen-devel mailing list
X
On Tue, Apr 18, 2017 at 04:18:52PM +0800, Lan Tianyu wrote:
> On 2017年04月17日 22:39, Konrad Rzeszutek Wilk wrote:
> > On Fri, Mar 17, 2017 at 07:27:03PM +0800, Lan Tianyu wrote:
> >> This patch is to add irq request callback for platform implementation
> >> to deal with irq remapping request.
> >>
>
On Tue, Apr 18, 2017 at 04:34:52PM +0800, Lan Tianyu wrote:
> On 2017年04月17日 22:43, Konrad Rzeszutek Wilk wrote:
> > On Fri, Mar 17, 2017 at 07:27:15PM +0800, Lan Tianyu wrote:
> >> From: Chao Gao
> >>
> >> When irq remapping enabled, IOAPIC Redirection Entry maybe is in remapping
> >> format. If
On Tue, Apr 18, 2017 at 06:35:57AM -0600, Jan Beulich wrote:
> >>> On 27.03.17 at 12:44, wrote:
> > --- a/xen/arch/x86/hvm/vioapic.c
> > +++ b/xen/arch/x86/hvm/vioapic.c
> > @@ -199,6 +199,34 @@ static void vioapic_write_redirent(
> > unmasked = unmasked && !ent.fields.mask;
> > }
>
On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote:
>
> Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper,
> rather than spreading it further.
>
> IMO, given reset_system is a *mandatory* function, the Xen wrapper
> should provide an implementation.
>
> I don't see why you c
On Thu, Apr 13, 2017 at 06:55:54PM +0200, Greg KH wrote:
> On Thu, Apr 13, 2017 at 06:28:33PM +0200, Juergen Gross wrote:
> > On 13/04/17 18:24, Greg KH wrote:
> > > On Thu, Apr 13, 2017 at 04:49:49PM +0200, Juergen Gross wrote:
> > >> Revert commit 72a9b186292 ("xen: Remove event channel notificat
On 18/04/17 15:52, Greg KH wrote:
> On Thu, Apr 13, 2017 at 06:55:54PM +0200, Greg KH wrote:
>> On Thu, Apr 13, 2017 at 06:28:33PM +0200, Juergen Gross wrote:
>>> On 13/04/17 18:24, Greg KH wrote:
On Thu, Apr 13, 2017 at 04:49:49PM +0200, Juergen Gross wrote:
> Revert commit 72a9b186292 ("
>>> On 18.04.17 at 15:44, wrote:
> On Tue, Apr 18, 2017 at 06:35:57AM -0600, Jan Beulich wrote:
>> >>> On 27.03.17 at 12:44, wrote:
>> > --- a/xen/arch/x86/hvm/vioapic.c
>> > +++ b/xen/arch/x86/hvm/vioapic.c
>> > @@ -199,6 +199,34 @@ static void vioapic_write_redirent(
>> > unmasked = un
> -Original Message-
[snip]
> >
> > Not quite sure I understand this. The QEMu device model does not 'pass
> DMA requests' as such, it maps guest RAM and reads or writes to emulate
> DMA, right? So, what's needed is a mechanism to map guest RAM by 'bus
> address'... i.e. an address that wil
1 - 100 of 153 matches
Mail list logo
