On Tue, 2015-09-22 at 15:15 +0100, George Dunlap wrote:
> On 09/22/2015 02:52 PM, Wu, Feng wrote:
> >
> >
> > > -Original Message-
> > > From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> > > Yes, the idle to vCPUB switch is covered by __context_switch(),
> > > but
> > it cannot c
On Tue, Sep 22, 2015 at 08:11:41AM -0600, Jan Beulich wrote:
> >>> On 22.09.15 at 16:03, wrote:
> > On Tue, Sep 22, 2015 at 07:52:19AM -0600, Jan Beulich wrote:
> >> >>> On 22.09.15 at 15:39, wrote:
> >> > On Tue, Sep 22, 2015 at 06:26:11AM -0700, Ed Swierk wrote:
> >> >> Any other ideas?
> >> >
On Tue, Sep 22, 2015 at 08:12:56AM -0600, Jan Beulich wrote:
> >>> On 22.09.15 at 16:09, wrote:
> > On Tue, Sep 22, 2015 at 07:57:29AM -0600, Jan Beulich wrote:
> >> >>> On 22.09.15 at 15:36, wrote:
> >> > The best I could come up with is to do two loops:
> >> > 1) for 0:0:0 -> ff:ff:ff call PHY
Hi Vijay,
On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Emulate GITS* registers
>
> Signed-off-by: Vijaya Kumar K
> ---
> v7: - Fixed wrong usage of vgic_regN* helpers
> - coding styles and comments
> - GITS_BASER0 is always overwritten with new value ever
On Tue, 2015-09-22 at 15:13 +0100, Andrew Cooper wrote:
> On 22/09/15 13:50, Jan Beulich wrote:
> > Adjust types, avoid a NULL check for a case where it's not needed, and
> > simplify setting a variable on the alternative path.
> >
> > Signed-off-by: Jan Beulich
>
> Reviewed-by: Andrew Cooper
A
>>> On 11.09.15 at 10:28, wrote:
> Remove pointless casts.
>
Suggested-by: Jan Beulich
> Signed-off-by: Feng Wu
> Reviewed-by: Konrad Rzeszutek Wilk
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 11.09.15 at 10:28, wrote:
> Extend struct iremap_entry according to VT-d Posted-Interrupts Spec.
>
> CC: Yang Zhang
> CC: Kevin Tian
> Signed-off-by: Feng Wu
> Acked-by: Kevin Tian
> ---
> v7:
> - Add a __uint128_t member to the union in struct iremap_entry
How about making use of thi
On 09/22/2015 02:25 PM, Wu, Feng wrote:
>>> But if we want to avoid spurious PI interrupts when running idle, then
>>> yes, we need *some* kind of a hook on the lazy context switch path.
>>>
>>> /me does some more thinking...
>>
>> To be honest, since we'll be get spurious PI interrupts in the
>> h
>>> On 11.09.15 at 10:28, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1701,8 +1701,35 @@ static void vmx_deliver_posted_intr(struct vcpu *v, u8
> vector)
> */
> pi_set_on(&v->arch.hvm_vmx.pi_desc);
> }
> -else if ( !pi_test_and_se
>>> On 21.09.15 at 16:02, wrote:
> In the EPT case permission changes should also result in updates or
> TLB flushes.
>
> In the NPT case the old MFN does not depend on the new entry being
> valid (but solely on the old one), and the need to update or TLB-flush
> again also depends on permission
>>> On 11.09.15 at 10:28, wrote:
> Extend struct pi_desc according to VT-d Posted-Interrupts Spec.
>
> Signed-off-by: Feng Wu
> Reviewed-by: Andrew Cooper
> Acked-by: Kevin Tian
> Reviewed-by: Konrad Rzeszutek Wilk
> ---
> v7:
> - Coding style.
Are you sure?
> --- a/xen/include/asm-x86/hvm/
>>> On 11.09.15 at 10:28, wrote:
> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
> With VT-d Posted-Interrupts enabled, external interrupts from
> direct-assigned devices can be delivered to guests without VMM
> intervention when guest is running in non-root mode.
>
> Sig
On 09/22/2015 02:52 PM, Wu, Feng wrote:
>
>
>> -Original Message-
>> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
>> Sent: Tuesday, September 22, 2015 9:40 PM
>> To: Wu, Feng; George Dunlap
>> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
>> Coope
On Tue, Aug 18, 2015 at 09:49:43AM +0200, Roger Pau Monné wrote:
> El 12/08/15 a les 16.09, Konrad Rzeszutek Wilk ha escrit:
> > On Fri, Aug 07, 2015 at 04:58:57PM +0200, Roger Pau Monné wrote:
> >> El 07/08/15 a les 16.54, Konrad Rzeszutek Wilk ha escrit:
> >>> Ok. I hadn't run your patch yet. Do
>>> On 22.09.15 at 16:09, wrote:
> On Tue, Sep 22, 2015 at 07:57:29AM -0600, Jan Beulich wrote:
>> >>> On 22.09.15 at 15:36, wrote:
>> > The best I could come up with is to do two loops:
>> > 1) for 0:0:0 -> ff:ff:ff call PHYSDEVOP_pci_device_remove
>> > (so blow away what Xen has for its PC
On 22/09/15 13:50, Jan Beulich wrote:
Adjust types, avoid a NULL check for a case where it's not needed, and
simplify setting a variable on the alternative path.
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-d
>>> On 22.09.15 at 16:03, wrote:
> On Tue, Sep 22, 2015 at 07:52:19AM -0600, Jan Beulich wrote:
>> >>> On 22.09.15 at 15:39, wrote:
>> > On Tue, Sep 22, 2015 at 06:26:11AM -0700, Ed Swierk wrote:
>> >> Any other ideas?
>> >
>> > I like it - as it will update it right away. However we would need
On Tue, Sep 22, 2015 at 07:57:29AM -0600, Jan Beulich wrote:
> >>> On 22.09.15 at 15:36, wrote:
> > The best I could come up with is to do two loops:
> > 1) for 0:0:0 -> ff:ff:ff call PHYSDEVOP_pci_device_remove
> > (so blow away what Xen has for its PCI devices.. except for the AMD
> > IOMM
On Tue, Sep 22, 2015 at 09:00 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Sep 22, 2015 at 01:42:14PM +0200, Mike Belopuhov wrote:
> > On Fri, Sep 18, 2015 at 10:13 -0400, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Sep 18, 2015 at 08:00:28AM -0400, Boris Ostrovsky wrote:
> > > >
> > > >
> > > >
The copyright line indicates a person, a group of people and/or a company
granting rights stated in the license text and is a required part of the
license.
The year of the copyright is chosen to be the same as when the license has
been applied to the file or when the file has been created in case
On Tue, Sep 22, 2015 at 07:52:19AM -0600, Jan Beulich wrote:
> >>> On 22.09.15 at 15:39, wrote:
> > On Tue, Sep 22, 2015 at 06:26:11AM -0700, Ed Swierk wrote:
> >> Any other ideas?
> >
> > I like it - as it will update it right away. However we would need some
> > extra smarts in Xen to reconfigu
>>> On 22.09.15 at 15:40, wrote:
>
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, September 22, 2015 5:00 PM
>> To: Wu, Feng
>> Cc: Andrew Cooper; Dario Faggioli; George Dunlap; George Dunlap; Tian,
> Kevin;
>> xen-devel@lists.xen.org; Keir Frase
>>> On 22.09.15 at 15:36, wrote:
> The best I could come up with is to do two loops:
> 1) for 0:0:0 -> ff:ff:ff call PHYSDEVOP_pci_device_remove
> (so blow away what Xen has for its PCI devices.. except for the AMD
> IOMMU)
> 2) list_for_each_pci_device PHYSDEVOP_pci_device_add (or other va
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 22, 2015 9:51 PM
> To: Wu, Feng
> Cc: Andrew Cooper; xen-devel@lists.xen.org; Keir Fraser
> Subject: Re: [PATCH v7 02/17] Add cmpxchg16b support for x86-64
> > +#define cmpxchg16b(ptr,o,n)
> \
>
>>> On 22.09.15 at 15:39, wrote:
> On Tue, Sep 22, 2015 at 06:26:11AM -0700, Ed Swierk wrote:
>> Any other ideas?
>
> I like it - as it will update it right away. However we would need some
> extra smarts in Xen to reconfigure its view of the PCI device now that the
> extended configuration space
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Tuesday, September 22, 2015 9:40 PM
> To: Wu, Feng; George Dunlap
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v
>>> On 11.09.15 at 10:28, wrote:
> --- a/xen/include/asm-x86/x86_64/system.h
> +++ b/xen/include/asm-x86/x86_64/system.h
> @@ -6,6 +6,37 @@
> (unsigned long)(n),sizeof(*(ptr
>
> /*
> + * Atomic 16 bytes compare and exchange. Compare OLD with MEM, if
> +
Hi Vijay,
On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K
>
> Add Virtual ITS command processing support to Virtual ITS driver
>
> Signed-off-by: Vijaya Kumar K
I've got minor comments in vits_get_max_collections. With that addressed:
Reviewed-by: Julien Grall
[...
On Tue, Sep 22, 2015 at 02:33:23PM +0100, Andrew Cooper wrote:
> On 22/09/15 14:22, Konrad Rzeszutek Wilk wrote:
> >On Fri, Sep 18, 2015 at 12:40:46PM +0100, Andrew Cooper wrote:
> >>On 17/09/15 19:45, Konrad Rzeszutek Wilk wrote:
> >>>. snip..
> The build id of the current running hypervis
On 22/09/15 14:24, Jan Beulich wrote:
On 22.09.15 at 15:17, wrote:
On 22/09/15 13:45, Jan Beulich wrote:
+static void do_adj_thresh(unsigned char key)
+{
+if ( *upper_thresh_adj < *lower_thresh_adj )
+*upper_thresh_adj = *lower_thresh_adj;
+printk("'%c' pressed -> %s log level:
On Tue, 2015-09-22 at 13:25 +, Wu, Feng wrote:
>
> > -Original Message-
> > From: George Dunlap [mailto:george.dun...@citrix.com]
> Specifically, consider the following scheduling case happened on
> pCPUA:
> vCPUA --> idle --> vCPUB
>
> 1. First, vCPUA is running on pCPUA, so the ND
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, September 22, 2015 5:00 PM
> To: Wu, Feng
> Cc: Andrew Cooper; Dario Faggioli; George Dunlap; George Dunlap; Tian, Kevin;
> xen-devel@lists.xen.org; Keir Fraser
> Subject: RE: [Xen-devel] [PATCH v7 15/17]
On Tue, Sep 22, 2015 at 06:26:11AM -0700, Ed Swierk wrote:
> On Tue, Sep 22, 2015 at 5:35 AM, Ed Swierk wrote:
> > So if the contract is that Dom0 tells Xen about mmcfgs before the
> > devices they cover, then Linux ought to call pci_mmcfg_reserved from
> > (or immediately after) both pci_mmcfg_ea
On Fri, Sep 18, 2015 at 10:13 -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Sep 18, 2015 at 08:00:28AM -0400, Boris Ostrovsky wrote:
> >
> >
> > On 09/18/2015 04:44 AM, Ian Campbell wrote:
> > >On Thu, 2015-09-17 at 13:53 +0200, Mike Belopuhov wrote:
> > >
> > >A few words here about the methodol
Hello Ian,
As requested I have attached the gdb output of the code.
On 22 September 2015 at 15:21, Ian Campbell wrote:
> On Tue, 2015-09-22 at 14:50 +0530, kumara rathnavel wrote:
>
> > > I have attached my code. I have also attached the system call traces
> file
> > > which was generated by th
On Mon, Sep 21, 2015 at 11:23:03PM -0600, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk 09/21/15 8:06 PM >>>
> >- Never figured out how much data we should save in the Xen's
> >struct pci_device to see if we are 'stale'. Looking back I think
> >we just need to do the interogation of the PCI capab
Citerar Andrew Cooper :
On 21/09/2015 21:03, Andreas Sundstrom wrote:
Using 64-bit dom0 and 32-bit domU PV (para-virtualized) grub sometimes
fail when chainloading the domU's grub. 64-bit domU seem to work 100%
of the time.
You say sometimes. Do you mean that repeated attempts to boot a 32b
>>> On 22.09.15 at 15:26, wrote:
> On Tue, Sep 22, 2015 at 5:35 AM, Ed Swierk wrote:
>> So if the contract is that Dom0 tells Xen about mmcfgs before the
>> devices they cover, then Linux ought to call pci_mmcfg_reserved from
>> (or immediately after) both pci_mmcfg_early_init() and
>> pci_mmcfg_
On 22/09/15 14:22, Konrad Rzeszutek Wilk wrote:
On Fri, Sep 18, 2015 at 12:40:46PM +0100, Andrew Cooper wrote:
On 17/09/15 19:45, Konrad Rzeszutek Wilk wrote:
. snip..
The build id of the current running hypervisor should belong in the
xeninfo hypercall. It is not specific to xsplice.
Howeve
>>> On 22.09.15 at 15:02, wrote:
> On 22/09/15 13:53, Jan Beulich wrote:
>> Rather than dirtying a page when establishing a (permanent) mapping,
>> dirty it when the page gets unmapped, or - if still mapped - on the
>> final iteration of a save operation (or in other cases where the guest
>> is pa
On Tue, Sep 22, 2015 at 5:35 AM, Ed Swierk wrote:
> So if the contract is that Dom0 tells Xen about mmcfgs before the
> devices they cover, then Linux ought to call pci_mmcfg_reserved from
> (or immediately after) both pci_mmcfg_early_init() and
> pci_mmcfg_late_init().
Brainstorming possible app
On 22/09/15 10:10, Vijay Kilari wrote:
> On Mon, Sep 21, 2015 at 7:50 PM, Julien Grall wrote:
>> That's really ugly and you still let GICv2 hardware with nr_lpis != 0.
>> As said on v6 I don't want to see any usage of nr_lpis in code except
>> for letting the user restricting the number of LPIs su
> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: Tuesday, September 22, 2015 6:46 PM
> To: Wu, Feng; Dario Faggioli
> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
> Cooper; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v7
>>> On 22.09.15 at 15:17, wrote:
> On 22/09/15 13:45, Jan Beulich wrote:
>> +static void do_adj_thresh(unsigned char key)
>> +{
>> +if ( *upper_thresh_adj < *lower_thresh_adj )
>> +*upper_thresh_adj = *lower_thresh_adj;
>> +printk("'%c' pressed -> %s log level: %s (rate limited %s)
On Fri, Sep 18, 2015 at 12:40:46PM +0100, Andrew Cooper wrote:
> On 17/09/15 19:45, Konrad Rzeszutek Wilk wrote:
> > . snip..
> >> The build id of the current running hypervisor should belong in the
> >> xeninfo hypercall. It is not specific to xsplice.
> > However in the previous revi
On 22/09/15 08:33, Vijay Kilari wrote:
> On Mon, Sep 21, 2015 at 7:17 PM, Julien Grall wrote:
>> On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
>>> From: Vijaya Kumar K
>>>
>>> Add APIs to add devices to RB-tree, assign and remove
>>> devices to domain.
>>>
> [...]
>>> +
>>> +static void its_fr
On 22/09/15 13:45, Jan Beulich wrote:
... so that one doesn't always need to reboot to see more / fewer
messages.
Note that upper thresholds are sticky, i.e. while they get adjusted
upwards when the lower threshold would otherwise end up above the upper
one, they don't get adjusted when reducing
... in order to also intercept accesses through the alias ports.
Also stop intercepting accesses to the CMOS ports if we won't ourselves
use the CMOS RTC.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1544,42 +1544,6 @@ int __hwdom_init xen_in_range(unsign
... in anticipation of this possibly going to get used by guests for
basic thinks like memset() or clearing or pages.
Since the emulation doesn't use clzero itself, checking the guest's
CPUID for the feature to be exposed is (intentionally) being avoided
here. All that's required is sensible guest
On 22/09/15 14:01, Jan Beulich wrote:
While neither PoD together with pass-through nor PVH are currently
supported we still shouldn't leave in place such latent issues.
Signed-off-by: Jan Beulich
Reviewed-by: Tim Deegan
Reviewed-by: Andrew Cooper
___
On 22/09/15 13:59, Jan Beulich wrote:
... by grouping sequences of contiguous CPUs.
Signed-off-by: Jan Beulich
Much nicer. Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 22/09/15 13:53, Jan Beulich wrote:
Rather than dirtying a page when establishing a (permanent) mapping,
dirty it when the page gets unmapped, or - if still mapped - on the
final iteration of a save operation (or in other cases where the guest
is paused or already shut down). (Transient mapping
While neither PoD together with pass-through nor PVH are currently
supported we still shouldn't leave in place such latent issues.
Signed-off-by: Jan Beulich
Reviewed-by: Tim Deegan
---
To apply cleanly this needs to have
http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg02719.html
On Tue, Sep 22, 2015 at 01:42:14PM +0200, Mike Belopuhov wrote:
> On Fri, Sep 18, 2015 at 10:13 -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 18, 2015 at 08:00:28AM -0400, Boris Ostrovsky wrote:
> > >
> > >
> > > On 09/18/2015 04:44 AM, Ian Campbell wrote:
> > > >On Thu, 2015-09-17 at 13:53
... by grouping sequences of contiguous CPUs.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -365,7 +365,7 @@ EXPORT_SYMBOL(node_data);
static void dump_numa(unsigned char key)
{
s_time_t now = NOW();
-unsigned int i, j;
+unsigned int i, j, n;
When mapping large BARs (e.g. the frame buffer of a graphics card) the
overhead of establishing such mappings using only 4k pages has,
particularly after the XSA-125 fix, become unacceptable. Alter the
XEN_DOMCTL_memory_mapping semantics once again, so that there's no
longer a fixed amount of guest
Rather than dirtying a page when establishing a (permanent) mapping,
dirty it when the page gets unmapped, or - if still mapped - on the
final iteration of a save operation (or in other cases where the guest
is paused or already shut down). (Transient mappings continue to get
dirtied upon getting m
On Tue, 2015-09-22 at 13:41 +0100, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH XEN v2 08/15] tools:
> Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab."):
> > On 22/09/15 12:25, Ian Campbell wrote:
> > > Any thoughts/preferences on this library interface regarding:
PDX-es are 64 bits wide in that case, and hence no limit needs to be
enforced.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
v2: Use "const unsigned int bits = 0" instead of #define / #undef
(as suggested by IanC).
--- unstable.orig/xen/arch/x86/domai
Adjust types, avoid a NULL check for a case where it's not needed, and
simplify setting a variable on the alternative path.
Signed-off-by: Jan Beulich
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -92,7 +92,7 @@ static void increase_reservation(struct
static void populate_physmap(stru
... so that one doesn't always need to reboot to see more / fewer
messages.
Note that upper thresholds are sticky, i.e. while they get adjusted
upwards when the lower threshold would otherwise end up above the upper
one, they don't get adjusted when reducing the lower one.
Signed-off-by: Jan Beul
Processing commands for x...@bugs.xenproject.org:
> close 44
Closing bug #44
> thanks
Finished processing.
Modified/created Bugs:
- 44: http://bugs.xenproject.org/xen/bug/44
---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on
reporting bugs
Andrew Cooper writes ("Re: [Xen-devel] [PATCH XEN v2 08/15] tools: Refactor
/dev/xen/gnt{dev, shr} wrappers into libxengnttab."):
> On 22/09/15 12:25, Ian Campbell wrote:
> > Any thoughts/preferences on this library interface regarding:
> >
> > The use of a (perhaps to be added) grant_ref_t in pre
>>> On 22.09.15 at 14:35, wrote:
> On Mon, Sep 21, 2015 at 10:21 PM, Jan Beulich wrote:
>> I don't follow: Surely Dom0 first establishes MCFG areas to be used, and
>> only then scans the buses for devices, resulting in them to be reported to
>> the hypervisor?
>
> That seems like a reasonable ex
On 22/09/15 11:34, Vijay Kilari wrote:
> On Mon, Sep 21, 2015 at 4:53 PM, Julien Grall wrote:
>> Maybe you want to add the suffix _cmd to everyone to avoid having only
>> one because of C spec issue.
>
> suffixing _cmd will look ugly ( as below ex) where "cmd" is repeated twice.
Well, you alread
On Mon, Sep 21, 2015 at 10:21 PM, Jan Beulich wrote:
> I don't follow: Surely Dom0 first establishes MCFG areas to be used, and
> only then scans the buses for devices, resulting in them to be reported to
> the hypervisor?
That seems like a reasonable expectation, but while Linux 4.2 finds
the mm
Ian Campbell writes ("[PATCH OSSTEST] production-config-cambridge: Use
git-cache.daemon.osstest.xs.citrite.net"):
> This currently points to drall, so no actual change, but it decouples
> the service from the host which happens to run it.
Acked-by: Ian Jackson
__
On Tue, 2015-09-22 at 17:19 +0530, kumara rathnavel wrote:
> Hello Ian,
>
> As requested I have attached the gdb output of the code.
You need to build with debugging symbols included, or to avoid stripping
them, otherwise the stack trace just contains interpretable.
If you are unfamiliar with d
On 22/09/15 11:44, Ian Campbell wrote:
> On Tue, 2015-09-22 at 11:29 +0100, Julien Grall wrote:
>>
>> On 22/09/2015 11:05, Ian Campbell wrote:
>>> On Tue, 2015-09-22 at 10:45 +0100, Julien Grall wrote:
On 22/09/2015 10:17, Vijay Kilari wrote:
>> Why do you need a command line option t
close 44
thanks
On Tue, 2015-09-22 at 13:12 +0100, Lars Kurth wrote:
> Folks,
> this bug should probably be closed.
I think you meant #44. I've closed that here.
Anyone can close any bug, no special privilege is required
See http://wiki.xen.org/wiki/Xen_Bug_Management_Interface.
Ian.
Remove unused fields from the domain builder and associated functions.
Signed-off-by: Juergen Gross
---
V2: correct python keyword parsing (Wei Liu)
---
tools/libxc/include/xc_dom.h | 2 --
tools/python/xen/lowlevel/xc/xc.c | 10 +++---
2 files changed, 3 insertions(+), 9 deletions(-)
Hi tools maintainers,
On 09/11/2015 02:32 PM, Juergen Gross wrote:
The Xen hypervisor supports starting a dom0 with large memory (up to
the TB range) by not including the initrd and p2m list in the initial
kernel mapping. Especially the p2m list can grow larger than the
available virtual space i
Folks,
this bug should probably be closed.
Lars
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 22/09/15 12:25, Ian Campbell wrote:
Any thoughts/preferences on this library interface regarding:
The use of a (perhaps to be added) grant_ref_t in preference to uint32_t as
it is now?
Probably a good idea. We should also introduce/use domid_t consistently
through the new API as well.
This currently points to drall, so no actual change, but it decouples
the service from the host which happens to run it.
Signed-off-by: Ian Campbell
---
production-config-cambridge | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/production-config-cambridge b/production-config
Any thoughts/preferences on this library interface regarding:
The use of a (perhaps to be added) grant_ref_t in preference to uint32_t as
it is now?
The use of bool rather than int for "writeable"?
Mapping functions returning NULL on failure (rather than e.g MAP_FAILED)?
(current code squashes a
On 22/09/15 11:35, Jan Beulich wrote:
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1858,15 +1858,9 @@ static void vmcs_dump(unsigned char ch)
printk("**\n");
}
-static struct keyhandler vmcs_dump_keyhandler = {
-.dia
On Mon, 2015-09-14 at 17:23 +0200, Roger Pau Monné wrote:
> I'm not saying that we shouldn't take those patches, I'm just saying
> that IMHO this is a workaround, and I would like to see a plan and
> somebody committed to have it fixed in a proper way, by introducing a
> 64KB PV block protocol.
In
On 09/22/2015 11:43 AM, George Dunlap wrote:
> On 09/22/2015 06:10 AM, Wu, Feng wrote:
>>
>>
>>> -Original Message-
>>> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
>>> Sent: Monday, September 21, 2015 10:12 PM
>>> To: Wu, Feng; George Dunlap
>>> Cc: xen-devel@lists.xen.org; Tian
On Tue, 2015-09-22 at 11:29 +0100, Julien Grall wrote:
>
> On 22/09/2015 11:05, Ian Campbell wrote:
> > On Tue, 2015-09-22 at 10:45 +0100, Julien Grall wrote:
> > >
> > > On 22/09/2015 10:17, Vijay Kilari wrote:
> > > > > Why do you need a command line option to enable/disable the
> > > > > physi
On 09/22/2015 06:10 AM, Wu, Feng wrote:
>
>
>> -Original Message-
>> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
>> Sent: Monday, September 21, 2015 10:12 PM
>> To: Wu, Feng; George Dunlap
>> Cc: xen-devel@lists.xen.org; Tian, Kevin; Keir Fraser; George Dunlap; Andrew
>> Coope
On Tue, 2015-09-22 at 10:34 +, osstest service owner wrote:
> flight 62189 linux-3.4 running [real]
> http://logs.test-lab.xenproject.org/osstest/logs/62189/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
>>> On 14.09.15 at 15:49, wrote:
> key_table doesn't need to contain 256 entries; all keys are ASCII
> which limits them to 7 bits of index, rather than 8. It can also
> become a straight array, rather than an array of pointers. struct
> keyhandler itself can become smaller simply via reordering
On Tue, 2015-09-22 at 10:05 +0100, Ian Campbell wrote:
> On Tue, 2015-09-22 at 00:23 +, osstest service owner wrote:
> > flight 62156 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/62156/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocki
flight 62189 linux-3.4 running [real]
http://logs.test-lab.xenproject.org/osstest/logs/62189/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub queued
test-amd64-amd64-xl-qemuu
On Mon, Sep 21, 2015 at 4:53 PM, Julien Grall wrote:
> Hi Vijay,
>
> The only things I haven't check on this patch was the ITS command structure.
>
> On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
>> +/* ITS command structure */
>> +typedef union {
>
> Can you please sort this union by command n
On 22/09/2015 11:05, Ian Campbell wrote:
On Tue, 2015-09-22 at 10:45 +0100, Julien Grall wrote:
On 22/09/2015 10:17, Vijay Kilari wrote:
Why do you need a command line option to enable/disable the physical
ITS?
I have added this to remove ITS support?.
Did I misunderstood it. May be I have
On 09/22/2015 08:19 AM, Wu, Feng wrote:
>
>
>> -Original Message-
>> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
>> Sent: Monday, September 21, 2015 10:25 PM
>> To: Wu, Feng; George Dunlap; George Dunlap
>> Cc: Jan Beulich; Tian, Kevin; Keir Fraser; Andrew Cooper;
>> xen-devel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory XSA-142
libxl fails to honour readonly flag on disks with qemu-xen
ISSUE DESCRIPTION
=
Callers of libxl can specify that a disk should be read-only to the
guest. However, there is no
On Tue, 2015-09-22 at 10:45 +0100, Julien Grall wrote:
>
> On 22/09/2015 10:17, Vijay Kilari wrote:
> > > Why do you need a command line option to enable/disable the physical
> > > ITS?
> >
> > I have added this to remove ITS support?.
> > Did I misunderstood it. May be I have to avoid generating
Hi Vijay,
On 22/09/2015 10:55, Vijay Kilari wrote:
On Mon, Sep 21, 2015 at 4:53 PM, Julien Grall wrote:
Hi Vijay,
The only things I haven't check on this patch was the ITS command structure.
[...]
Why a padding of only 56 bits? Shouldn't it be 248 bits (i.e 31 * 8
bits) to fit all the comm
On Mon, Sep 21, 2015 at 4:53 PM, Julien Grall wrote:
> Hi Vijay,
>
> The only things I haven't check on this patch was the ITS command structure.
[...]
> Why a padding of only 56 bits? Shouldn't it be 248 bits (i.e 31 * 8
> bits) to fit all the command?
>
>> +} hdr;
>> +struct __packed {
>
On Tue, 2015-09-22 at 14:50 +0530, kumara rathnavel wrote:
> > I have attached my code. I have also attached the system call traces file
> > which was generated by the command truss for the command that was
> > successful through XL and the other one that failed where I used the call
> > directly.
On 22/09/2015 10:17, Vijay Kilari wrote:
Why do you need a command line option to enable/disable the physical ITS?
I have added this to remove ITS support?.
Did I misunderstood it. May be I have to avoid generating its dt node
to disable its for dom0?
My question is why do you want to let t
>>> On 22.09.15 at 11:05, wrote:
> On Tue, 2015-09-22 at 00:23 +, osstest service owner wrote:
>> flight 62156 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/62156/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests whi
Tools maintainers,
it looks as if changes in the memory requirements of the hypervisor
have pushed things over the border of not working anymore when
passing through a device and not sharing page tables (between VT-d
and EPT, or unconditionally on AMD). Since this has always been a
latent issue (a
>
>
> Hello All,
>
> I am not able to use the library functions provided by the LibXenlight
> though I am able to use it through XL. I am in need to develop my own CLI
> . I am able to perform few basic operations like listing the VM, reboot
> and all. But the calls that require a structure to be f
Hi,
On 22/09/2015 08:15, Andrew Cooper wrote:
On 22/09/2015 08:04, Jan Beulich wrote:
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
Some of these are overly Intel-specific, but while AMD has no
implementation, this isn't much of a problem.
Note that on ARM, we are only using off|
On Mon, Sep 21, 2015 at 8:50 PM, Julien Grall wrote:
> Hi Vijay,
>
> On 18/09/15 14:09, vijay.kil...@gmail.com wrote:
>> From: Vijaya Kumar K
>>
>> Initialize physical ITS if HW supports LPIs.
>>
>> Signed-off-by: Vijaya Kumar K
>> ---
>> v7: - Export lpi support information to vgic-v3 driver fr
On Mon, Sep 21, 2015 at 7:50 PM, Julien Grall wrote:
> Hi Vijay,
>
> On 18/09/15 14:08, vijay.kil...@gmail.com wrote:
>> From: Vijaya Kumar K
>>
>> Helper function gic_is_lpi() is used to find
>> if irq is lpi or not. For GICv2 platforms this function
>> returns number of irq ids which represents
101 - 200 of 215 matches
Mail list logo
