flight 59631 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59631/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail
REGR. vs. 58965
tes
On Do, 2015-07-16 at 17:47 +0200, Juergen Gross wrote:
> Today a host usb device can be specified either via :
> or via . syntax. Add the possibility to specify it via
> - as this is needed for the support of xen pvusb backend.
-device usb-host,hostbus=,hostport= should already do what
you want.
This patch enables xsaves for hvm guest, includes:
1.handle xsaves vmcs init and vmexit.
2.add logic to write/read the XSS msr.
Signed-off-by: Shuai Ruan
---
xen/arch/x86/hvm/hvm.c | 39 ++
xen/arch/x86/hvm/vmx/vmcs.c| 7 ++-
xen/arch/
This patch uses xsaves/xrstors instead of xsaveopt/xrstor
to perform the xsave_area switching so that xen itself
can benefit from them when available.
Please note that xsaves/xrstors only use compact format.
Signed-off-by: Shuai Ruan
---
xen/arch/x86/i387.c | 5
xen/arch/x86/xsta
As xsaves/xgetbv1 already support, so switch on.
Signed-off-by: Shuai Ruan
---
xen/arch/x86/xstate.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 0eea146..a3f5c67 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/
xsaves/xrstors only use compat format, so format convertion
is needed when perform save/restore.
Signed-off-by: Shuai Ruan
---
xen/arch/x86/domain.c| 3 +
xen/arch/x86/hvm/hvm.c | 16 +++--
xen/arch/x86/xstate.c| 138 +++
xen/inclu
Changes in v2:
* Address comments from Andrew/chao/Jan, mainly:
* Add details information of xsaves/xrstors feature.
* Remove XGETBV1/XSAVEC/XSAVEOPT out of 'else' in patch 3.
* Change macro name XGETBV to XGETBV1 in patch 4.
This patchset enable xsaves/xrstors feature which will be available on
This patch emualtes xsaves/xrstors instructions and
XSS msr access.
As xsaves/xrstors instructions and XSS msr access
required be executed only in ring0. So emulation are
needed when pv guest uses these instructions.
Signed-off-by: Shuai Ruan
---
xen/arch/x86/domain.c | 3 ++
xen/arc
This patch exposes xsaves/xgetbv1/xsavec to hvm guest.
Signed-off-by: Shuai Ruan
---
tools/libxc/xc_cpuid_x86.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index c97f91a..28347fd 100644
--- a/tools/libxc/xc_c
On Fri, 2015-07-17 at 07:09 +0100, Jan Beulich wrote:
> >>> On 16.07.15 at 18:59, wrote:
> > And in general (both for PV and HVM) --- is there any reason to expose
> > CPU topology at all? I can see it being useful if VCPUs are pinned but
> > if they are not then it can make performance worse.
>
On 07/17/2015 08:59 AM, Gerd Hoffmann wrote:
On Do, 2015-07-16 at 17:47 +0200, Juergen Gross wrote:
Today a host usb device can be specified either via :
or via . syntax. Add the possibility to specify it via
- as this is needed for the support of xen pvusb backend.
-device usb-host,hostbus=,h
>>> On 17.07.15 at 02:45, wrote:
> Now use the hypervisor-supplied memory map to build our final e820 table:
> * Add regions for BIOS ranges and other special mappings not in the
> hypervisor map
> * Add in the hypervisor regions
... hypervisor supplied regions?
> --- a/tools/firmware/hvmloade
>>> On 17.07.15 at 09:27, wrote:
> In the meanwhile, what should we do? Document this? How? "don't use
> vNUMA with PV guest in SMT enabled systems" seems a bit harsh... Is
> there a workaround we can put in place/suggest?
Use SLE / openSUSE kernels ;-) ?
Jan
__
Hi, Ian. Thank You for tips.
On Mon, Jul 13, 2015 at 12:04 PM, Ian Campbell wrote:
> There is an additional quirk for a 1:1 mapped dom0 which is that we
> don't actually decrease reservation when ballooning, but keep the 1:1
> mfn in anticipation of ballooning it back in later.
Currently we have
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Wednesday, July 15, 2015 12:03 AM
> To: Wu, Feng
> Cc: Jan Beulich; Tian, Kevin; k...@xen.org; George Dunlap;
> andrew.coop...@citrix.com; xen-devel; Zhang, Yang Z
> Subject: Re: [Xen-devel] Fwd: [v3 14
>>> On 17.07.15 at 09:26, wrote:
> @@ -247,8 +250,7 @@ static void xc_cpuid_config_xsave(
> regs[1] = 512 + 64; /* FP/SSE + XSAVE.HEADER */
> break;
> case 1: /* leaf 1 */
> -regs[0] &= XSAVEOPT;
> -regs[1] = regs[2] = regs[3] = 0;
This deletion as well as .
On Do, 2015-07-16 at 17:47 +0200, Juergen Gross wrote:
> In order to avoid having to poll for the result of an iso transfer
> add the possibility to request the "complete" callback which is being
> used for bulk transfers as well.
Sorry for the late notice (didn't do much usb coding recently and f
Ok, Thanks Jan.
I will add the descriptions in next version.
Below is the short descriptions.
For CPUID with eax=0xd and ecx=0x1, ebx\ecx\edx may not be zero when xsaves
supported. Also with ecx>2, ecx\edx may not be zero. If we want expose xsaves
to HVM guest , we should not set them to zero.
On Fr, 2015-07-17 at 09:32 +0200, Juergen Gross wrote:
> On 07/17/2015 08:59 AM, Gerd Hoffmann wrote:
> > On Do, 2015-07-16 at 17:47 +0200, Juergen Gross wrote:
> >> Today a host usb device can be specified either via :
> >> or via . syntax. Add the possibility to specify it via
> >> - as this is n
On 07/17/2015 10:12 AM, Gerd Hoffmann wrote:
On Do, 2015-07-16 at 17:47 +0200, Juergen Gross wrote:
In order to avoid having to poll for the result of an iso transfer
add the possibility to request the "complete" callback which is being
used for bulk transfers as well.
Sorry for the late notic
On Fri, Jul 17, 2015 at 09:27:55AM +0200, Dario Faggioli wrote:
> On Fri, 2015-07-17 at 07:09 +0100, Jan Beulich wrote:
> > >>> On 16.07.15 at 18:59, wrote:
> > > And in general (both for PV and HVM) --- is there any reason to expose
> > > CPU topology at all? I can see it being useful if VCPUs a
On Thu, 2015-07-16 at 20:32 +0100, Andrew Cooper wrote:
> The socket option takes a mandatory argument. Mark it as such, so
> optarg isn't NULL when passed to trim(), which unconditionally
> dereference it.
>
> Range check optind against argc before blindly assuming that
> argv[optind] and argv[o
On Fri, 2015-07-17 at 10:43 +0300, Oleksandr Dmytryshyn wrote:
> Hi, Ian. Thank You for tips.
>
> On Mon, Jul 13, 2015 at 12:04 PM, Ian Campbell
> wrote:
> > There is an additional quirk for a 1:1 mapped dom0 which is that we
> > don't actually decrease reservation when ballooning, but keep the
On Thu, Jul 16, 2015 at 05:58:27PM +0100, Ian Campbell wrote:
> The removal of the udev rules highlighted that although it has been
> replaced by "xl devd" there isn't an initscript to replace it.
>
> To enable this add a --pidfile option to xl devd.
>
> Tested on Linux by running the script in d
The way it's written I take it that you assume there to be exactly
one region that the adjustment needs to be done for. Iirc this is
correct with the current model, but why would you continue the
loop then afterwards? Placing a "break" in the if()'s body would
document the fact that only one such
On Fri, Jul 17, 2015 at 09:16:08AM +0800, Chen, Tiejun wrote:
> On 2015/7/14 17:29, Wei Liu wrote:
> >On Tue, Jul 14, 2015 at 09:27:17AM +0800, Chen, Tiejun wrote:
> >>>Please work with maintainers to get those hvmloader patches acked or
> >>>reviewed.
> >>
> >>I will do.
>
> Maybe I need to updat
> > --- a/hw/usb/host-libusb.c
> > +++ b/hw/usb/host-libusb.c
> > @@ -451,6 +451,7 @@ static void usb_host_req_complete_iso(struct
> > libusb_transfer *transfer)
> > }
> > if (xfer->ring->ep->pid == USB_TOKEN_IN) {
> > QTAILQ_INSERT_TAIL(&xfer->ring->copy, xfer, next);
> > +
* On hvmloader side, there three patches now:
patch #5 is reviewed by George and Acked by Jan;
patch #6 is reviewed just for code implementation but that solution can't
convince all maintainers. Honestly, this is a rare possibility of collision
in real world and the original pci allocation i
On Thu, Jul 16, 2015 at 10:15 PM, Chen, Tiejun wrote:
>>
>> base = (resource->base + bar_sz - 1) & ~(uint64_t)(bar_sz - 1);
>> +
>> +/* If we're using mem_resource, check for RMRR conflicts */
>> +while ( resource == &mem_resource &&
>> +next_rmrr > 0 &&
Remind me again please - what prevents the highmem region from
colliding with hypervisor supplied entries?
Also, what if the resulting region exceeds the addressable range
(guest's view of CPUID[8008].EAX[0:7])?
Any idea to this? I think this issue also exists previously.
Thanks
Tiejun
__
On Wed, Jul 15, 2015 at 10:48:31PM +, Wu, Feng wrote:
>
>
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: Wednesday, July 15, 2015 11:47 PM
> > To: Jan Beulich
> > Cc: Wei Liu; andrew.coop...@citrix.com; George Dunlap; Wu, Feng; Tian,
> > Kevin;
> > Zh
On Fri, Jul 17, 2015 at 05:24:55PM +0800, Chen, Tiejun wrote:
> >>* On hvmloader side, there three patches now:
> >> patch #5 is reviewed by George and Acked by Jan;
> >> patch #6 is reviewed just for code implementation but that solution can't
> >>convince all maintainers. Honestly, this is a
Andrew Cooper writes ("[PATCH] tools/xl: Fix trim() following c/s e316316 "xl:
Rewrite trim()""):
> c/s e316316 "xl: Rewrite trim()" uses the wrong indirection of
> 'output', causing memory corruption for all callers.
>
> Introduce a new local variable, making the code more obviously
> correct.
Wei Liu writes ("Re: [PATCH] tools/xl: Fix trim() following c/s e316316 "xl:
Rewrite trim()""):
> C90 forbids this. Not sure how much we care about that and I'm probably
> bicksheding too much.
libxl/Makefile has -Wno-declaration-after-statement
Ian.
On 07/17/2015 10:28 AM, Gerd Hoffmann wrote:
On Fr, 2015-07-17 at 09:32 +0200, Juergen Gross wrote:
On 07/17/2015 08:59 AM, Gerd Hoffmann wrote:
On Do, 2015-07-16 at 17:47 +0200, Juergen Gross wrote:
Today a host usb device can be specified either via :
or via . syntax. Add the possibility to
Andrew Cooper writes ("[PATCH] tools/xl: Fix segfaults from `xl
psr-cat-cbm-set` command line handling"):
> The socket option takes a mandatory argument. Mark it as such, so
> optarg isn't NULL when passed to trim(), which unconditionally
> dereference it.
>
> Range check optind against argc bef
Hi all,
I'm working on an x86 proof-of-concept series to evaluate if it is
feasible to move device models currently running in the hypervisor and
x86 emulation code for HVM guests into a deprivileged context.
I've put together the following document as I have been considering
several differe
On 07/17/2015 11:23 AM, Gerd Hoffmann wrote:
--- a/hw/usb/host-libusb.c
+++ b/hw/usb/host-libusb.c
@@ -451,6 +451,7 @@ static void usb_host_req_complete_iso(struct
libusb_transfer *transfer)
}
if (xfer->ring->ep->pid == USB_TOKEN_IN) {
QTAILQ_INSERT_TAIL(&xfer->ring->copy
Hi Christopher,
Thank you for the patch.
It looks like the mail as been sent in HTML. Can you resend it in plain
text?
You also need to cc the maintainers of the code you are modifying (I've
CCed them this time).
You can give a look to [1] to know how to send correctly the patch.
On 16/07/15
On Fri, 2015-07-17 at 07:46 +, Wu, Feng wrote:
> Hi Dario,
>
Hi,
> I finished the new patch with arch hooks, but seems something is wrong,
> after assigning the NIC to guest, I ping some guy from the guest, the
> latency is too big.
>
Ok. What numbers are we talking about, just to have an id
On 16/07/15 17:59, Boris Ostrovsky wrote:
> On 07/16/2015 12:39 PM, Andrew Cooper wrote:
>> On 16/07/15 17:29, Jan Beulich wrote:
>> On 16.07.15 at 17:50, wrote:
Can't we set leaf 1's EBX[32:16] to 1?
>
> (I obviously fat-fingered this --- I meant EBX[23:16])
>
>>> I don't think we should
Wei Liu writes ("Re: [Xen-devel] Request a freeze exception for COLO in v4.6"):
> Ian and Ian, anything to add? What are your opinions?
I think COLO is an exciting and important feature.
Unfortunately I agree with Wei that at this stage taking both series
as they currently stand into 4.6 is not t
On Thu, 2015-07-16 at 23:30 +0100, Wei Liu wrote:
> On Thu, Jul 16, 2015 at 10:53:02PM +0100, Andrew Cooper wrote:
> > On 16/07/2015 21:47, Wei Liu wrote:
> > > On Thu, Jul 16, 2015 at 08:18:31PM +0100, Andrew Cooper wrote:
> > >> c/s e316316 "xl: Rewrite trim()" uses the wrong indirection of
> > >
Hi,
> > device_add monitor command.
>
> Okay. I guess the USBDevice for the added device can be obtained
> in USBPortOps->attach via USBPort->dev ?
Yes.
> Doing a quick search through the sources I couldn't find a way to
> issue a monitor command from inside qemu. I assume I'd have to use
> d
On 07/17/2015 12:23 PM, Gerd Hoffmann wrote:
Hi,
device_add monitor command.
Okay. I guess the USBDevice for the added device can be obtained
in USBPortOps->attach via USBPort->dev ?
Yes.
Doing a quick search through the sources I couldn't find a way to
issue a monitor command from ins
Il 17/07/2015 12:09, Ben Catterall ha scritto:
Hi all,
I'm working on an x86 proof-of-concept series to evaluate if it is
feasible to move device models currently running in the hypervisor and
x86 emulation code for HVM guests into a deprivileged context.
I've put together the following docu
On 17/07/15 11:27, Fabio Fantoni wrote:
> Il 17/07/2015 12:09, Ben Catterall ha scritto:
>> Hi all,
>>
>> I'm working on an x86 proof-of-concept series to evaluate if it is
>> feasible to move device models currently running in the hypervisor
>> and x86 emulation code for HVM guests into a deprivil
>>> On 17.07.15 at 10:10, wrote:
> Ok, Thanks Jan.
> I will add the descriptions in next version.
>
> Below is the short descriptions.
> For CPUID with eax=0xd and ecx=0x1, ebx\ecx\edx may not be zero when xsaves
> supported. Also with ecx>2, ecx\edx may not be zero. If we want expose xsaves
>
On 16/07/15 22:36, Sahita, Ravi wrote:
> Hi Wei and Maintainers,
>
> While we continue to work on the maintainer review comments - we prepared a
> minor incremental version v6 of our patch series that :
>
> 1. is rebased to staging
> 2. addresses a bug that we found/introduced in v5
>
> The intent
>>> On 17.07.15 at 11:09, wrote:
>> And then of course there's the question of whether "nr" is really
>> the right upper loop bound here: Just prior to this you added
>> the hypervisor supplied entries - why would you need to iterate
>> over them here? I.e. I'd see this better be moved ahead of th
On Fri, Jul 17, 2015 at 11:18:21AM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] Request a freeze exception for COLO in
> v4.6"):
> > Ian and Ian, anything to add? What are your opinions?
>
> I think COLO is an exciting and important feature.
>
> Unfortunately I agree with Wei tha
>>> On 17.07.15 at 11:27, wrote:
>> Remind me again please - what prevents the highmem region from
>> colliding with hypervisor supplied entries?
>>
>> Also, what if the resulting region exceeds the addressable range
>> (guest's view of CPUID[8008].EAX[0:7])?
>
> Any idea to this? I think th
>>> On 17.07.15 at 11:26, wrote:
> Given that if we run out of MMIO space, all that happens is that some
> devices will not really work, I think this solution is really no worse
> than the "disable devices on conflict" solution; and it's better,
> because you can actually work around it by increas
flight 59634 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59634/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 11 guest-saverestore fail REGR. vs.
59059
test-amd64-i3
On Fri, Jul 17, 2015 at 11:51:16AM +0100, Andrew Cooper wrote:
> On 16/07/15 22:36, Sahita, Ravi wrote:
> > Hi Wei and Maintainers,
> >
> > While we continue to work on the maintainer review comments - we
> > prepared a minor incremental version v6 of our patch series that :
> >
> > 1. is rebased t
On Fri, 2015-07-17 at 10:05 +0100, Wei Liu wrote:
> On Thu, Jul 16, 2015 at 05:58:27PM +0100, Ian Campbell wrote:
> > The removal of the udev rules highlighted that although it has been
> > replaced by "xl devd" there isn't an initscript to replace it.
> >
> > To enable this add a --pidfile option
> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Ben Catterall
> Sent: 17 July 2015 11:10
> To: xen-devel@lists.xen.org; Andrew Cooper; jbeul...@suse.com
> Subject: [Xen-devel] RFC on deprivileged x86 hypervisor device mod
Konrad Rzeszutek Wilk writes:
...
>> +return AO_CREATE_FAIL(ERROR_FAIL);
>> +}
>> +
>> +/*
>> + * On the domain creation path it will be introduced to xenstore
>
> What is 'it'?
>
The domain :-)
>> + * with (probably) different store/console channels so we need to
>> +
Konrad Rzeszutek Wilk writes:
>>
>> @@ -1010,6 +1017,29 @@ int domain_unpause_by_systemcontroller(struct domain
>> *d)
>> return 0;
>> }
>>
>> +int domain_soft_reset(struct domain *d)
>> +{
>> +struct vcpu *v;
>> +int rc;
>> +
>> +spin_lock(&d->shutdown_lock);
>> +for_e
flight 59639 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59639/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 30511
Tests which are failing
Hi Stefano,
On 16/07/15 18:12, Stefano Stabellini wrote:
> On Thu, 9 Jul 2015, Julien Grall wrote:
>> The hypercall interface (as well as the toolstack) is always using 4KB
>> page granularity. When the toolstack is asking for mapping a series of
>> guest PFN in a batch, it expects to have the pag
On Thu, 16 Jul 2015, Julien Grall wrote:
> Hi Stefano,
>
> On 16/07/2015 16:43, Stefano Stabellini wrote:
> > On Thu, 9 Jul 2015, Julien Grall wrote:
> > > Only use the first 4KB of the page to store the events channel info. It
> > > means that we will wast 60KB every time we allocate page for:
>
On 16/07/15 17:07, Julien Grall wrote:
>>> +pfn = xen_page_to_pfn(page) + (offset >> XEN_PAGE_SHIFT);
>>> +
>>> +while (len) {
>>> +glen = min_t(unsigned int, XEN_PAGE_SIZE - goffset, len);
>>
>> Similarly I don't think we want to support glen != XEN_PAGE_SIZE here
>
> See my answe
flight 59640 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59640/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 58581
Regressions which are
Additional logging is as useful here as for create.
Signed-off-by: Ian Campbell
---
Osstest/Toolstack/xl.pm | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index 3c3d348..becda7d 100644
--- a/Osstest/Toolstack/xl.pm
+++
On Fri, Jul 17, 2015 at 10:30:41AM +0100, Wei Liu wrote:
> On Fri, Jul 17, 2015 at 05:24:55PM +0800, Chen, Tiejun wrote:
> > >>* On hvmloader side, there three patches now:
> > >> patch #5 is reviewed by George and Acked by Jan;
> > >> patch #6 is reviewed just for code implementation but that
On Thu, 16 Jul 2015, Julien Grall wrote:
> Hi Stefano,
>
> On 16/07/2015 16:33, Stefano Stabellini wrote:
> > On Fri, 10 Jul 2015, Konrad Rzeszutek Wilk wrote:
> > > On Thu, Jul 09, 2015 at 09:42:21PM +0100, Julien Grall wrote:
> > > > When Linux is using 64K page granularity, every page will be s
These result in log messages such as:
(XEN) d0v0: vGICD: RAZ on reserved register offset 0x0c
(XEN) d0v0: vGICR: write r2 offset 0x000180
(XEN) not found<3>traps.c:2417:d0v0 HSR=0x93820046 pc=0xffc000322bfc
gva=0xff890180 gpa=0x008d110180
Fix this by rewording without a \n i
Hi all,
Here's v2 of this series. v1 is here:
http://lists.xen.org/archives/html/xen-devel/2015-07/msg00647.html
As a quick recap, this is aimed at avoiding an host crash during shutdown or
suspension, it in the following cases:
- when the boot cpu (i.e., most of the times, cpu 0) is not assign
The function is called both when we want to remove a cpu
from a cpupool, and during cpu teardown, for suspend or
shutdown. If, however, the boot cpu (cpu 0, most of the
times) is not present in the default cpupool, during
suspend or shutdown, Xen crashes like this:
root@Zhaman:~# xl cpupool-cpu-
And this time, do it right. In fact, a similar change was
attempted in 93be8285a79c6 ("cpupools: update domU's node-affinity
on the cpupool_unassign_cpu() path"). But that was buggy, and got
reverted with 8395b67ab0b8a86.
However, even though reverting was the right thing to do, it
remains true th
>>> On 17.07.15 at 15:21, wrote:
> The major concern seems to be around the PCI allocation algorithm. Jan
> has different opinion from George. George provided a simple solution
> that will not make things worse than before, while Jan prefers to get
> everything right.
>
> To be fair, the PCI allo
On Thu, 16 Jul 2015, Julien Grall wrote:
> Hi Stefano,
>
> On 16/07/2015 16:47, Stefano Stabellini wrote:
> >> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> > > index 3679293..0a1f903 100644
> > > --- a/drivers/xen/grant-table.c
> > > +++ b/drivers/xen/grant-table.c
> >
>
>>> On 17.07.15 at 02:45, wrote:
> When allocating mmio address for PCI bars, mmio may overlap with
> reserved regions. Currently we just want to disable these associate
> devices simply to avoid conflicts but we will reshape current mmio
> allocation mechanism to fix this completely.
>
> CC: Kei
On Tue, 2015-07-07 at 15:54 -0400, Boris Ostrovsky wrote:
> Commit 63753fac67e1 ("x86: Store a per-cpu shadow copy of CR4") in
> 3.18.y branch introduced a regression on PVH Xen guests.
>
> Please apply 5054daa285be ("x86/xen: Initialize cr4 shadow for 64-bit
> PV(H) guests") from mainline to fi
On Fri, Jul 17, 2015 at 02:43:05PM +0100, Jan Beulich wrote:
> >>> On 17.07.15 at 15:21, wrote:
> > The major concern seems to be around the PCI allocation algorithm. Jan
> > has different opinion from George. George provided a simple solution
> > that will not make things worse than before, while
On Thu, 9 Jul 2015, Julien Grall wrote:
> For ARM64 guests, Linux is able to support either 64K or 4K page
> granularity. Although, the hypercall interface is always based on 4K
> page granularity.
>
> With 64K page granuliarty, a single page will be spread over multiple
> Xen frame.
>
> When a d
The DOMCTLs {,un}bind_pt_irq are using uint32_t for the machine_irq
while the helper is using uint8_t.
Currently on ARM, we are supporting SPIs whose irq number can go up to
1019 which doesn't fit in an uint8_t. The helpers xc_domain_bind_pt_spi
and xc_domain_unbint_pt_spi are correctly taking an
On 07/17/2015 09:59 AM, Ian Campbell wrote:
On Tue, 2015-07-07 at 15:54 -0400, Boris Ostrovsky wrote:
Commit 63753fac67e1 ("x86: Store a per-cpu shadow copy of CR4") in
3.18.y branch introduced a regression on PVH Xen guests.
Please apply 5054daa285be ("x86/xen: Initialize cr4 shadow for 64-bit
Hi Ian,
On 17/07/15 14:21, Ian Campbell wrote:
> These result in log messages such as:
>
> (XEN) d0v0: vGICD: RAZ on reserved register offset 0x0c
> (XEN) d0v0: vGICR: write r2 offset 0x000180
> (XEN) not found<3>traps.c:2417:d0v0 HSR=0x93820046 pc=0xffc000322bfc
> gva=0xff89018
>>> On 17.07.15 at 12:09, wrote:
> Moving between privilege levels
>
> The general process is to determine if we need to run a device model (or
> similar) and then, if so, switch into deprivileged mode. The operation
> is performed by deprivileged code which call
---
v9:
* A little improvement to code implementation but again, its still argued about
this solution.
And as said in reply to George's reply to v8 - the alternative he
proposed is still better than this one, and would therefore have
better chances of me agreeing to take what is there instea
Hi Julien,
On Wed, Jul 15, 2015 at 6:27 PM, Julien Grall wrote:
> Hi Vijay,
>
> On 10/07/2015 09:42, 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
>>
>> ---
>> v4: - Use helper
My main disagreement here continues to be that we're talking
about a bug fix, and hence I don't view this as needing a freeze
exception in the first place (at least not at this point in time). Yes,
the bug fix involves adding code that looks like a new feature, but
that happens with bug fixes.
Hi Stefano,
On 17/07/15 15:03, Stefano Stabellini wrote:
>> ---
>> drivers/xen/balloon.c | 147
>> +++---
>> 1 file changed, 105 insertions(+), 42 deletions(-)
>>
>> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
>> index fd93369..19a72b1 1
flight 59650 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59650/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-xsm 11 guest-start fail REGR. vs. 58842
Regressions which are reg
On 17/07/15 14:20, Stefano Stabellini wrote:
> We would have to run some benchmarks, but I think it would still be a
> win. We should write an ad-hoc __pfn_to_mfn translation function that
> operates on a range of pfns and simply checks whether an entry is
> present in that range. It should be just
On Fri, 17 Jul 2015, Julien Grall wrote:
> On 17/07/15 14:20, Stefano Stabellini wrote:
> > We would have to run some benchmarks, but I think it would still be a
> > win. We should write an ad-hoc __pfn_to_mfn translation function that
> > operates on a range of pfns and simply checks whether an en
On 17/07/15 15:45, Stefano Stabellini wrote:
> On Fri, 17 Jul 2015, Julien Grall wrote:
>> On 17/07/15 14:20, Stefano Stabellini wrote:
>>> We would have to run some benchmarks, but I think it would still be a
>>> win. We should write an ad-hoc __pfn_to_mfn translation function that
>>> operates on
Hi Ian,
On Mon, Jul 13, 2015 at 5:07 PM, Ian Campbell wrote:
> On Mon, 2015-07-13 at 16:45 +0530, Vijay Kilari wrote:
>
>> BTW, I want to know if atomic_t supports 64-bit access?.
>
> I don't know off the top of my head. I'm sure it would be apparent in
> the code.
atomic_t is 32 bit. But CREAD
On Thu, Jul 16, 2015 at 05:43:36PM -0400, Boris Ostrovsky wrote:
> x86-64 ABI requires that functions preserve %rbx. When
> xen_pvh_early_cpu_init() is executed on boot cpu it is invoked as a
> function and 'cpuid' instruction will clobber %rbx. (This is not a
> concern on secondary processors sinc
On 17/07/15 15:01, Wei Liu wrote:
> On Fri, Jul 17, 2015 at 02:43:05PM +0100, Jan Beulich wrote:
> On 17.07.15 at 15:21, wrote:
>>> The major concern seems to be around the PCI allocation algorithm. Jan
>>> has different opinion from George. George provided a simple solution
>>> that will not
On 17/07/15 15:12, Vijay Kilari wrote:
> Hi Julien,
Hi Vijay,
> On Wed, Jul 15, 2015 at 6:27 PM, Julien Grall wrote:
>> On 10/07/2015 09:42, vijay.kil...@gmail.com wrote:
>>>
>>> From: Vijaya Kumar K
>>>
>>> Add Virtual ITS command processing support to Virtual ITS driver
>>>
>>> Signed-off-by:
On 17/07/15 15:20, Jan Beulich wrote:
On 17.07.15 at 12:09, wrote:
Moving between privilege levels
The general process is to determine if we need to run a device model (or
similar) and then, if so, switch into deprivileged mode. The operation
is performed by d
On Thu, Jul 16, 2015 at 05:43:39PM -0400, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky
> ---
> Changes in v2:
> * Set segment selectors using loadsegment() instead of assembly
>
> arch/x86/xen/enlighten.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> di
On Thu, Jul 16, 2015 at 05:43:40PM -0400, Boris Ostrovsky wrote:
> Signed-off-by: Boris Ostrovsky
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> Changes in v2:
> * Some code reshuffling due to changes in patch 1.
>
> arch/x86/xen/enlighten.c | 4
> arch/x86/xen/smp.c | 16 +
On 2015/7/17 18:50, Jan Beulich wrote:
On 17.07.15 at 11:09, wrote:
And then of course there's the question of whether "nr" is really
the right upper loop bound here: Just prior to this you added
the hypervisor supplied entries - why would you need to iterate
over them here? I.e. I'd see this b
On Thu, 2 Jul 2015, Konrad Rzeszutek Wilk wrote:
> In Xen 4.6 commit cd2f100f0f61b3f333d52d1737dd73f02daee592
> "libxc: Fix do_memory_op to return negative value on errors"
> made the libxc API less odd-ball: On errors, return value is
> -1 and error code is in errno. On success the return value
>
The PCI allocation code is in a state, but it was in a similarly bad
state before. I agree with Jan's point of the risk that these new
changes cause a regression in booting guests, although we can mitigate
that somewhat by testing.
I feel at this point that we shouldn't block the RMRR bugfix on
On Thu, 2 Jul 2015, Konrad Rzeszutek Wilk wrote:
> We would like to know what the MSI register value is to help
> in troubleshooting in the field. As such modify the logging
> logic to include such details in xen_pt_msgctrl_reg_write.
>
> Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Stefano
1 - 100 of 191 matches
Mail list logo
