Hi All,
I am working custom platform based on x86_64 running 3.10 kernel,
Recently I found an issue related to GARP. It seems like no GARP
packets are being sent out when an Interface is made up. But I also
noticed that only when I use "arping" tool only then it sends out any
GARP packet.
I also
Hello everyone,
I'd like to solicit comments on improvements to the RTDS scheduler for Xen
4.6.
The following regards changes to the RTDS scheduler, in line with our
expected next steps as mentioned on the feature wiki page:
http://wiki.xenproject.org/wiki/RTDS-Based-Scheduler#Features_that_are_p
>>> On 20.02.15 at 18:33, wrote:
> On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
>> > That's the issue we are trying to resolve, with device tree there is no
>> > explicit segment ID, so we have an essentially unindexed set of PCI
>> > buses in both Xen and dom0.
>>
>> How that? What if t
flight 34922 seabios real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34922/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 5 xen-boot fail REGR. vs. 33391
test-amd64-i386-xl
Hi,
While shutting down all guests to go for a host reboot i encountered the splat
below.
This was running on Xen with:
xen_changeset: Fri Feb 20 16:21:10 2015 +0100 git:24b2b8d-dirty
--
Sander
(XEN) [2015-02-23 09:16:26.292] Assertion 'cpu < nr_cpu_ids' failed at
.../src/new/xen-unstable/xen/
Don't kill xenstored as part of the usual service shutdown process to
prevent hangs on shutdown where the kernel tries to unplug a VIF
after xenstored has exited.
Signed-off-by: Ross Lagerwall
---
tools/hotplug/Linux/systemd/xenstored.service.in | 1 +
1 file changed, 1 insertion(+)
diff --git
>>> On 20.02.15 at 17:53, wrote:
> Jan, do you have any feeling for how this is going to play out on x86
> with the vapic stuff?
The vapic logic shouldn't require any physdevop involvement, so if
I read right what you propose (not having such a requirement /
connection on ARM) either, I agree tha
Moved the definition of struct xenpf_efi_guid up, and rearranged
struct xenpf_efi_time in the containing union to avoid compilation
errors with C++ (structs defined inside unnamed structs become
unavailable outside their scope with C++). The change allows C++
applications to use platform.h with no
Copying the stable tools maintainer (as requested by the MAINTAINERS
file).
On Sat, 2015-02-21 at 15:56 +0100, Marek Marczykowski-Górecki wrote:
> I'd like to have below two commits in stable release - without them
> libvirtd crashes while trying to start a HVM domain (with about 50%
> probability
>>> On 20.02.15 at 18:46, wrote:
> On 20/02/15 17:03, Ian Campbell wrote:
>> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>>
>> Subject: "release the DT devices assigned to a guest earlier"
>>
>>> The toolstack may not have deassign every device used by a guest.
>>
>> "deassigned"
>>
>>> On 20.02.15 at 18:04, wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>> Currently, when the device is deassigned from a domain, we directly reassign
>> to DOM0.
>>
>> As the device may not have been correctly reset, this may lead to corruption
> or
>> expose some part of DOM
On Fri, 2015-02-20 at 18:01 -0500, Daniel De Graaf wrote:
> On 02/20/2015 10:58 AM, Julien Grall wrote:
> > Each class can contains 32 permisions which are encoded on a word (one
> > bit per permission).
> >
> > Currently the awk script will generate an hexadecimal value for each
> > permission. Th
>>> On 21.02.15 at 19:14, wrote:
> Use u8-sized node IDs and unsigned PXMs consistently throughout
> code (and introduce nodeid_t type).
>
> Signed-off-by: Boris Ostrovsky
I think the description should call out areas not covered, like the
node encoding in the top bits of MEMF_*.
> --- a/xen/a
>>> On 23.02.15 at 10:27, wrote:
> While shutting down all guests to go for a host reboot i encountered the
> splat below.
> This was running on Xen with:
> xen_changeset: Fri Feb 20 16:21:10 2015 +0100 git:24b2b8d-dirty
"-dirty" meaning what?
> (XEN) [2015-02-23 09:16:26.292] Assertion 'cpu <
Ping? Do I need any more acks/reviews for this patch?
~Andrew
On 12/02/15 20:08, Andrew Cooper wrote:
> Coverity uses several heuristics to identify when one case statement
> legitimately falls through into the next, and a comment as the final item in a
> case statement is one heuristic (the ass
Hi Jan,
On 23/02/2015 09:40, Jan Beulich wrote:
On 20.02.15 at 18:04, wrote:
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
Currently, when the device is deassigned from a domain, we directly reassign
to DOM0.
As the device may not have been correctly reset, this may lead to corrupti
On 20/02/2015 17:04, Ian Campbell wrote:
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
Currently, when the device is deassigned from a domain, we directly reassign
to DOM0.
As the device may not have been correctly reset, this may lead to corruption or
expose some part of DOM0 memory
>>> On 23.02.15 at 10:34, wrote:
> Moved the definition of struct xenpf_efi_guid up, and rearranged
> struct xenpf_efi_time in the containing union to avoid compilation
> errors with C++ (structs defined inside unnamed structs become
> unavailable outside their scope with C++). The change allows C
>>> On 23.02.15 at 11:10, wrote:
> Hi Jan,
>
> On 23/02/2015 09:40, Jan Beulich wrote:
> On 20.02.15 at 18:04, wrote:
>>> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
Currently, when the device is deassigned from a domain, we directly
reassign
to DOM0.
As
On 02/23/2015 12:16 PM, Jan Beulich wrote:
On 23.02.15 at 10:34, wrote:
>> Moved the definition of struct xenpf_efi_guid up, and rearranged
>> struct xenpf_efi_time in the containing union to avoid compilation
>> errors with C++ (structs defined inside unnamed structs become
>> unavailable ou
On 23/02/15 10:06, Jan Beulich wrote:
On 23.02.15 at 10:27, wrote:
>> While shutting down all guests to go for a host reboot i encountered the
>> splat below.
>> This was running on Xen with:
>> xen_changeset: Fri Feb 20 16:21:10 2015 +0100 git:24b2b8d-dirty
> "-dirty" meaning what?
>
>> (XE
On Fri, 2015-02-20 at 15:07 +, Julien Grall wrote:
> On 20/02/15 13:55, Ian Campbell wrote:
> > On Fri, 2015-02-20 at 13:42 +, Julien Grall wrote:
> - Use num_s2crs rather than num_streamids in the arm_smmu_free_smrs.
> This former is the field used to configure SRMS
> >>>
Monday, February 23, 2015, 11:06:25 AM, you wrote:
On 23.02.15 at 10:27, wrote:
>> While shutting down all guests to go for a host reboot i encountered the
>> splat below.
>> This was running on Xen with:
>> xen_changeset: Fri Feb 20 16:21:10 2015 +0100 git:24b2b8d-dirty
> "-dirty" meanin
On 23/02/2015 10:42, Ian Campbell wrote:
On a side note, we consider this platform deprecated we should either
drop the code from Xen or write on the wiki that we don't fully support
it anymore.
It's all about degrees, I think we are fine to support the existing
feature set and commit to keep
>>> On 23.02.15 at 11:31, wrote:
> On 02/23/2015 12:16 PM, Jan Beulich wrote:
> On 23.02.15 at 10:34, wrote:
>>> Moved the definition of struct xenpf_efi_guid up, and rearranged
>>> struct xenpf_efi_time in the containing union to avoid compilation
>>> errors with C++ (structs defined inside
>>> On 23.02.15 at 11:38, wrote:
> On 23/02/15 10:06, Jan Beulich wrote:
> On 23.02.15 at 10:27, wrote:
>>> While shutting down all guests to go for a host reboot i encountered the
>>> splat below.
>>> This was running on Xen with:
>>> xen_changeset: Fri Feb 20 16:21:10 2015 +0100 git:24b2b8
>>> On 23.02.15 at 11:45, wrote:
> Any instructions on how to figure that out ?
No need anymore - with Andrew's help it's now already clear what's
wrong.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 20/02/15 8:09 pm, Ian Campbell wrote:
On Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote:
Another option might be a new hypercall (assuming one doesn't already
exist) to register a PCI bus which would take e.g. the PCI CFG base
address and return a new u16 segment id to be used for all su
On 02/23/2015 12:54 PM, Jan Beulich wrote:
@@ -152,24 +159,24 @@ struct xenpf_efi_runtime_call {
xen_ulong_t status;
union {
#define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x0001
+struct xenpf_efi_time {
+uint16_t year;
+uint
I have no idea how I came to use __cpumask_set_cpu() there, the
conversion should have been set_bit() -> __set_bit(). The wrong
construct results in problems on systems with relatively few CPUs.
Reported-by: Sander Eikelenboom
Signed-off-by: Jan Beulich
--- a/xen/common/softirq.c
+++ b/xen/comm
At 10:54 + on 23 Feb (1424685241), Jan Beulich wrote:
> ... this should be moved out to file scope too, both for consistency
> and to avoid an eventual further adjustment going forward. Otoh
> I'm not convinced we need the headers to be C++ ready (nor am
> I convinced that there aren't any othe
On 23/02/2015 10:59, Manish Jaggi wrote:
On 20/02/15 8:09 pm, Ian Campbell wrote:
On Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote:
Another option might be a new hypercall (assuming one doesn't already
exist) to register a PCI bus which would take e.g. the PCI CFG base
address and retur
Monday, February 23, 2015, 12:06:00 PM, you wrote:
> I have no idea how I came to use __cpumask_set_cpu() there, the
> conversion should have been set_bit() -> __set_bit(). The wrong
> construct results in problems on systems with relatively few CPUs.
> Reported-by: Sander Eikelenboom
> Signed-
>>> On 23.02.15 at 12:05, wrote:
> As for the headers being C++ ready, there's already the precedent of at
> least my previous patch "xenctrl: Make the headers C++ friendly":
>
> http://www.gossamer-threads.com/lists/xen/devel/337788
>
> where it turned out that there's at least one other serio
>>> On 23.02.15 at 12:09, wrote:
> At 10:54 + on 23 Feb (1424685241), Jan Beulich wrote:
>> ... this should be moved out to file scope too, both for consistency
>> and to avoid an eventual further adjustment going forward. Otoh
>> I'm not convinced we need the headers to be C++ ready (nor am
>
On 02/23/2015 12:54 PM, Jan Beulich wrote:
> I'm not convinced we need the headers to be C++ ready (nor am
> I convinced that there aren't any other obstacles preventing their
> unmodified use in C++).
Sorry, I meant to answer the last part too. I'm using libxc and xenstore
headers, as well as the
Am 11.02.2015 um 04:51 hat Shailesh Kumar geschrieben:
> Hi,
>
> I am implementing read equivalent routine in qemu. Can some one
> help me understand control flow of the qemu read/write
> implementation.
>
> I am using xen-4.2.0 and qemu-1.6.1
>
> My requirement is simple:
>
> I have a 102
On Thu, 2015-01-29 at 11:03 +, Stefano Stabellini wrote:
> On Tue, 13 Jan 2015, Julien Grall wrote:
> > Let the user to pass additional nodes to the guest device tree. For this
> > purpose, everything in the node /passthrough from the partial device tree
> > will
> > be copied into the guest d
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> Let the user to pass additional nodes to the guest device tree. For this
> purpose, everything in the node /passthrough from the partial device tree will
> be copied into the guest device tree.
>
> The node /aliases will be also copied to al
On 23/02/15 4:44 pm, Julien Grall wrote:
On 23/02/2015 10:59, Manish Jaggi wrote:
On 20/02/15 8:09 pm, Ian Campbell wrote:
On Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote:
Another option might be a new hypercall (assuming one doesn't already
exist) to register a PCI bus which would t
On 23/02/15 11:06, Jan Beulich wrote:
> I have no idea how I came to use __cpumask_set_cpu() there, the
> conversion should have been set_bit() -> __set_bit(). The wrong
> construct results in problems on systems with relatively few CPUs.
>
> Reported-by: Sander Eikelenboom
> Signed-off-by: Jan Be
Julien Grall writes ("[PATCH v3 21/24] tools/(lib)xl: Add partial device tree
support for ARM"):
> Let the user to pass additional nodes to the guest device tree. For this
> purpose, everything in the node /passthrough from the partial device tree \
will
> be copied into the guest device tree.
Pl
flight 34925 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34925/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 5 xen-bootfail REGR. vs. 34629
test-amd64-amd64-xl-
xen.org writes ("[xen-unstable test] 34925: regressions - trouble:
broken/fail/pass"):
> flight 34925 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/34925/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
Ian Jackson writes ("Re: [PATCH v3 21/24] tools/(lib)xl: Add partial device
tree support for ARM"):
> Is this facility supposed to take untrusted or partially-trusted
> partial device trees ?
Also, is libfdt intended (and safe) for use with untrusted fdt blobs ?
Ian.
___
On Mon, 2015-02-23 at 08:43 +, Jan Beulich wrote:
> >>> On 20.02.15 at 18:33, wrote:
> > On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
> >> > That's the issue we are trying to resolve, with device tree there is no
> >> > explicit segment ID, so we have an essentially unindexed set of P
On Mon, 2015-02-23 at 10:52 +, Julien Grall wrote:
>
> On 23/02/2015 10:42, Ian Campbell wrote:
> >> On a side note, we consider this platform deprecated we should either
> >> drop the code from Xen or write on the wiki that we don't fully support
> >> it anymore.
> >
> > It's all about degree
On Thu, Feb 19, 2015 at 7:33 PM, Julien Grall wrote:
> On 19/02/15 07:17, vijay.kil...@gmail.com wrote:
>> From: Vijaya Kumar K
>>
>> For arm memory for 1024 irq descriptors are allocated
>> statically irrespective of number of interrupt supported
>> by the platform.
>>
>> With this patch, irq de
flight 35192 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35192/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken REGR. vs. 34580
test-amd64-amd64-libvirt
While converting to __cpumask_set_cpu() was correct, the first argument
passed should have been corrected to be "cpu" instead of "nr" at once.
The wrong construct results in problems on systems with relatively few
CPUs.
Reported-by: Sander Eikelenboom
Signed-off-by: Jan Beulich
---
v2: As Andrew
On 23/02/15 13:47, Jan Beulich wrote:
> While converting to __cpumask_set_cpu() was correct, the first argument
> passed should have been corrected to be "cpu" instead of "nr" at once.
> The wrong construct results in problems on systems with relatively few
> CPUs.
>
> Reported-by: Sander Eikelenbo
>>> On 23.02.15 at 13:01, wrote:
> On 23/02/15 11:06, Jan Beulich wrote:
>> I have no idea how I came to use __cpumask_set_cpu() there, the
>> conversion should have been set_bit() -> __set_bit(). The wrong
>> construct results in problems on systems with relatively few CPUs.
>>
>> Reported-by: Sa
>>> On 23.02.15 at 13:45, wrote:
> On Mon, 2015-02-23 at 08:43 +, Jan Beulich wrote:
>> >>> On 20.02.15 at 18:33, wrote:
>> > On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
>> >> > That's the issue we are trying to resolve, with device tree there is no
>> >> > explicit segment ID, so w
On Mon, 2015-02-23 at 14:07 +, Jan Beulich wrote:
> >>> On 23.02.15 at 13:45, wrote:
> > On Mon, 2015-02-23 at 08:43 +, Jan Beulich wrote:
> >> >>> On 20.02.15 at 18:33, wrote:
> >> > On Fri, 2015-02-20 at 15:15 +, Jan Beulich wrote:
> >> >> > That's the issue we are trying to resolve
On Thu, 2015-01-29 at 13:48 +, Julien Grall wrote:
> On 29/01/15 12:28, Stefano Stabellini wrote:
> > On Thu, 29 Jan 2015, Julien Grall wrote:
> >> On 29/01/15 11:07, Stefano Stabellini wrote:
> >>> On Tue, 13 Jan 2015, Julien Grall wrote:
> The partial device tree may contains phandle. Th
On Thu, 2015-01-29 at 13:51 +, Julien Grall wrote:
> On 29/01/15 12:31, Stefano Stabellini wrote:
> > On Thu, 29 Jan 2015, Julien Grall wrote:
> >> Hi Stefano,
> >>
> >> On 29/01/15 11:12, Stefano Stabellini wrote:
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> >>
On 02/23/2015 04:57 AM, Jan Beulich wrote:
On 21.02.15 at 19:14, wrote:
Use u8-sized node IDs and unsigned PXMs consistently throughout
code (and introduce nodeid_t type).
Signed-off-by: Boris Ostrovsky
I think the description should call out areas not covered, like the
node encoding in the
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 5651110..c10fd2f 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
Need a new LIBXL_HAVE here. Perhaps combined into an umbrella one
>>> On 23.02.15 at 15:33, wrote:
> On Mon, 2015-02-23 at 14:07 +, Jan Beulich wrote:
>> >>> On 23.02.15 at 13:45, wrote:
>> > In which case might we be at liberty to specify that on ARM+Device Tree
>> > systems (i.e. those where the f/w tables don't give an enumeration)
>> > there is a 1:1 ma
On Thu, 2015-01-29 at 15:06 +, Stefano Stabellini wrote:
> I don't think it is necessary to have two separate patches, but let's
> see what the libxl maintainers have to say.
For large changes having the split between introducing libxl side and
then using it can be useful, but this change is s
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> The option "dtdev" will be used to passthrough a non-PCI device described
> in the device tree to a guest.
>
> Signed-off-by: Julien Grall
> Cc: Ian Jackson
> Cc: Wei Liu
>
> ---
> Changes in v2:
> - libxl_device_dt has been
>>> On 23.02.15 at 15:42, wrote:
> On 02/23/2015 04:57 AM, Jan Beulich wrote:
> On 21.02.15 at 19:14, wrote:
>>> --- a/xen/arch/x86/srat.c
>>> +++ b/xen/arch/x86/srat.c
>>> @@ -21,44 +21,55 @@
>>> #include
>>> #include
>>>
>>> +#define MAX_PXM 255
>> Perhaps better (MAX_NUMNODES -
On Sun, 2015-02-22 at 00:31 -0500, Dagaen Golomb wrote:
> Hello everyone,
>
Hello,
> I'd like to solicit comments on improvements to the RTDS scheduler for
> Xen 4.6.
>
My first comment is that I'm happy that you guys are working on
this! :-)
> [Motivation]
>
> This change will increase the eff
On 02/23/2015 09:47 AM, Jan Beulich wrote:
On 23.02.15 at 15:42, wrote:
On 02/23/2015 04:57 AM, Jan Beulich wrote:
On 21.02.15 at 19:14, wrote:
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -21,44 +21,55 @@
#include
#include
+#define MAX_PXM 255
Perhaps better (MAX_N
On Mon, 2015-02-23 at 14:45 +, Jan Beulich wrote:
> >>> On 23.02.15 at 15:33, wrote:
> > On Mon, 2015-02-23 at 14:07 +, Jan Beulich wrote:
> >> >>> On 23.02.15 at 13:45, wrote:
> >> > In which case might we be at liberty to specify that on ARM+Device Tree
> >> > systems (i.e. those where
>>> On 17.02.15 at 00:05, wrote:
> This includes adding is_vmware_port_enabled
>
> This is a new domain_create() flag, DOMCRF_vmware_port. It is
> passed to domctl as XEN_DOMCTL_CDF_vmware_port.
As indicated before, I don't think this is a good use case for a
domain creation flag. Some of the o
Hi Daniel,
On 20/02/15 23:01, Daniel De Graaf wrote:
> On 02/20/2015 10:58 AM, Julien Grall wrote:
>> Each class can contains 32 permisions which are encoded on a word (one
>> bit per permission).
>>
>> Currently the awk script will generate an hexadecimal value for each
>> permission. This may re
>>> On 17.02.15 at 00:05, wrote:
> Enable no-fault of pio in x86_emulate for VMware port
???
> @@ -393,6 +393,11 @@ struct x86_emulate_ops
> enum x86_segment seg,
> unsigned long offset,
> struct x86_emulate_ctxt *ctxt);
> +
> +/* vmport_check */
> +int (*vmpor
Hi everyone,
On Thu, 2015-02-19 at 17:01 +, Mel Gorman wrote:
> On Thu, Feb 19, 2015 at 01:06:53PM +, David Vrabel wrote:
> I cannot think of a reason why this would fail for NUMA balancing on bare
> metal. The PAGE_NONE protection clears the present bit on p[te|md]_modify
> so the expect
On Fri, 2015-02-20 at 16:09 +, Julien Grall wrote:
> Hi Ian,
>
> On 20/02/15 15:15, Ian Campbell wrote:
> > On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> >> On ARM the virtual GIC may differ between each guest (emulated GIC version,
> >> number of SPIs...). Those informations are al
>>> On 23.02.15 at 15:53, wrote:
> On 02/23/2015 09:47 AM, Jan Beulich wrote:
> On 23.02.15 at 15:42, wrote:
>>> On 02/23/2015 04:57 AM, Jan Beulich wrote:
>>> On 21.02.15 at 19:14, wrote:
> --- a/xen/arch/x86/srat.c
> +++ b/xen/arch/x86/srat.c
> @@ -21,44 +21,55 @@
>
On 23/02/15 11:50, Manish Jaggi wrote:
>
> On 23/02/15 4:44 pm, Julien Grall wrote:
>>
>>
>> On 23/02/2015 10:59, Manish Jaggi wrote:
>>>
>>> On 20/02/15 8:09 pm, Ian Campbell wrote:
On Fri, 2015-02-20 at 19:44 +0530, Manish Jaggi wrote:
>> Another option might be a new hypercall (assumin
On Fri, 2015-02-20 at 17:01 +, Julien Grall wrote:
> >> diff --git a/docs/misc/arm/device-tree/passthrough.txt
> >> b/docs/misc/arm/device-tree/passthrough.txt
> >> new file mode 100644
> >> index 000..04645b3
> >> --- /dev/null
> >> +++ b/docs/misc/arm/device-tree/passthrough.txt
> >> @@
On Fri, 2015-02-20 at 17:03 +, Julien Grall wrote:
> On 20/02/15 15:42, Ian Campbell wrote:
> > On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> >> @@ -919,8 +943,14 @@ static int make_timer_node(const struct domain *d,
> >> void *fdt,
> >> return res;
> >> }
> >>
> >> -/* Map
On Wed, Feb 11, 2015 at 10:18:18AM -0700, Jim Fehlig wrote:
> Wei Liu wrote:
> > On Tue, Feb 10, 2015 at 11:01:46AM +, Ian Jackson wrote:
> >
> >> Wei Liu writes ("[PATCH 3/3] libxl: libxl__device_from_disk should
> >> retrieve backend from xenstore"):
> >>
> >>> ... if backend is not
On Thu, Feb 12, 2015 at 07:19:15PM +0800, Ard Biesheuvel wrote:
> This patch updates XenBusDxe to use the 16-bit compare and exchange
> function that was introduced for this purpose to the
> BaseSynchronizationLib. It also provides a new generic implementation
> of TestAndClearBit () using the same
On Fri, 2015-02-20 at 17:28 +, Julien Grall wrote:
> Hi Ian,
>
> On 20/02/15 16:07, Ian Campbell wrote:
> > More importantly: We have (hopefully) guaranteed elsewhere that an PPI
> > or SGI can never make it here, I take it. If that's the case then either
> > the comment should say that, or mo
On Fri, 2015-02-20 at 17:29 +, Julien Grall wrote:
> On 20/02/15 16:08, Ian Campbell wrote:
> > On Wed, 2015-01-28 at 18:26 +, Stefano Stabellini wrote:
> >
> >>> +int spi = irq - 32;
> >>
> >> unsigned int
> >
> > and underflow?
>
> No because there is a check (irq < 32) before
On Fri, 2015-02-20 at 17:41 +, Julien Grall wrote:
> >> +/* TODO: Handle eviction from LRs. For now, deny remove if the IRQ
> >> + * is inflight and not disabled.
> >
> > If we are ungracefully killing a guest doesn't this risk ending up with
> > an undestroyable domain? i.e. if the g
>>> On 23.02.15 at 16:02, wrote:
> On Mon, 2015-02-23 at 14:45 +, Jan Beulich wrote:
>> In which case the Dom0 OS doing so would need to communicate
>> its decisions to the hypervisor, as you suggest further down.
>
> So more concretely something like:
> #define PHYSDEVOP_pci_host_bri
On Mon, 2015-02-23 at 09:33 +, Jan Beulich wrote:
> >>> On 20.02.15 at 17:53, wrote:
> > Jan, do you have any feeling for how this is going to play out on x86
> > with the vapic stuff?
>
> The vapic logic shouldn't require any physdevop involvement, so if
> I read right what you propose (not
On Fri, 2015-02-20 at 17:43 +, Julien Grall wrote:
> On 20/02/15 16:56, Ian Campbell wrote:
> > On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> >> Signed-off-by: Julien Grall
> >
> > Is this function still needed in the new model which doesn't do
> > automatic mappings etc?
>
> It's
On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> +/* This limit is used by the hypercalls to restrict the size of the path */
> +#define DEVICE_TREE_MAX_PATHLEN 1024
Is this something you've made up or derived from the DT spec/ePAPR etc?
Apart from this the patch seems fine, clarifying t
On Fri, 2015-02-20 at 17:45 +, Julien Grall wrote:
> On 20/02/15 16:58, Ian Campbell wrote:
> > On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> >> This new function will correctly initialize the IOMMU page table for the
> >> current domain.
> >>
> >> Also use it in iommu_assign_dt_devi
On Mon, 2015-02-23 at 09:37 +, Jan Beulich wrote:
> >>> On 20.02.15 at 18:46, wrote:
> > On 20/02/15 17:03, Ian Campbell wrote:
> >> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> >>
> >> Subject: "release the DT devices assigned to a guest earlier"
> >>
> >>> The toolstack may not
On Mon, 2015-02-23 at 10:10 +, Julien Grall wrote:
>
> On 20/02/2015 17:04, Ian Campbell wrote:
> > On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> >> Currently, when the device is deassigned from a domain, we directly
> >> reassign
> >> to DOM0.
> >>
> >> As the device may not have
On Mon, 2015-02-23 at 10:20 +, Jan Beulich wrote:
> >>> On 23.02.15 at 11:10, wrote:
> > Hi Jan,
> >
> > On 23/02/2015 09:40, Jan Beulich wrote:
> > On 20.02.15 at 18:04, wrote:
> >>> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
> Currently, when the device is deassigned f
Hello Vijay,
On 23/02/15 13:04, Vijay Kilari wrote:
> On Thu, Feb 19, 2015 at 7:33 PM, Julien Grall wrote:
>> On 19/02/15 07:17, vijay.kil...@gmail.com wrote:
>>> From: Vijaya Kumar K
>>>
>>> For arm memory for 1024 irq descriptors are allocated
>>> statically irrespective of number of interrupt
Hi Ian,
On 23/02/15 15:12, Ian Campbell wrote:
> On Fri, 2015-02-20 at 17:01 +, Julien Grall wrote:
diff --git a/docs/misc/arm/device-tree/passthrough.txt
b/docs/misc/arm/device-tree/passthrough.txt
new file mode 100644
index 000..04645b3
--- /dev/null
+++ b/
Hi Charles,
It's good to see that someone else is tackling this problem. We have a similar
problem in XenServer; tapdisk3 is a user space backend (just like qemu-qdisk)
and therefore libxenstat is unable to pick up any statistics from it. In that
way, "xentop" also doesn't display any stats for
On 23/02/15 15:15, Ian Campbell wrote:
> On Fri, 2015-02-20 at 17:03 +, Julien Grall wrote:
>> On 20/02/15 15:42, Ian Campbell wrote:
>>> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
@@ -919,8 +943,14 @@ static int make_timer_node(const struct domain *d,
void *fdt,
On Mon, 2015-02-23 at 15:27 +, Jan Beulich wrote:
> >>> On 23.02.15 at 16:02, wrote:
> > On Mon, 2015-02-23 at 14:45 +, Jan Beulich wrote:
> >> In which case the Dom0 OS doing so would need to communicate
> >> its decisions to the hypervisor, as you suggest further down.
> >
> > So more c
Hi Ian,
On 23/02/15 15:20, Ian Campbell wrote:
> On Fri, 2015-02-20 at 17:28 +, Julien Grall wrote:
>> The priority is controlled by route_irq_to_guest and set statically
>> using GIC_PRI_IRQ.
>>
>> If we decide to hardcoded the priority here, we should drop the
>> parameter on gic_route_irq_g
On Mon, Feb 23, 2015 at 03:13:48PM +, Dario Faggioli wrote:
> Hi everyone,
>
> On Thu, 2015-02-19 at 17:01 +, Mel Gorman wrote:
> > On Thu, Feb 19, 2015 at 01:06:53PM +, David Vrabel wrote:
>
> > I cannot think of a reason why this would fail for NUMA balancing on bare
> > metal. The
Hi Ian,
On 23/02/15 15:22, Ian Campbell wrote:
> On Fri, 2015-02-20 at 17:29 +, Julien Grall wrote:
>> On 20/02/15 16:08, Ian Campbell wrote:
>>> On Wed, 2015-01-28 at 18:26 +, Stefano Stabellini wrote:
>>>
> +int spi = irq - 32;
unsigned int
>>>
>>> and underflow?
>>
On 20/02/15 15:15, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +, Julien Grall wrote:
>> On ARM the virtual GIC may differ between each guest (emulated GIC version,
>> number of SPIs...). Those informations are already known at the domain
>> creation
> "This information is already known
Hi Ian,
On 23/02/15 15:25, Ian Campbell wrote:
> On Fri, 2015-02-20 at 17:41 +, Julien Grall wrote:
>
+/* TODO: Handle eviction from LRs. For now, deny remove if the IRQ
+ * is inflight and not disabled.
>>>
>>> If we are ungracefully killing a guest doesn't this risk ending
Hi Ian,
On 20/02/15 16:53, Ian Campbell wrote:
> On Thu, 2015-01-29 at 12:33 +, Stefano Stabellini wrote:
>> On Thu, 29 Jan 2015, Julien Grall wrote:
>>> On 29/01/15 12:17, Stefano Stabellini wrote:
On Wed, 28 Jan 2015, Julien Grall wrote:
> Hi Stefano,
>
> On 28/01/15 18:52,
On Mon, 2015-02-23 at 15:47 +, Julien Grall wrote:
> Hi Ian,
>
> On 23/02/15 15:20, Ian Campbell wrote:
> > On Fri, 2015-02-20 at 17:28 +, Julien Grall wrote:
> >> The priority is controlled by route_irq_to_guest and set statically
> >> using GIC_PRI_IRQ.
> >>
> >> If we decide to hardcode
Hi Ian,
On 23/02/15 15:28, Ian Campbell wrote:
> On Mon, 2015-02-23 at 09:33 +, Jan Beulich wrote:
> On 20.02.15 at 17:53, wrote:
>>> Jan, do you have any feeling for how this is going to play out on x86
>>> with the vapic stuff?
>>
>> The vapic logic shouldn't require any physdevop invol
1 - 100 of 139 matches
Mail list logo
