>>> On 10.06.15 at 07:20, wrote:
> On 26/05/2015 21:58, Jan Beulich wrote
>> >>> On 13.05.16 at 09:50, wrote:
>> > +if (policy->policy == CPUFREQ_POLICY_PERFORMANCE) {
>> > +limits.no_turbo = 0;
>> > +limits.max_perf_pct = 100;
>> > +limits.max_perf = int_tofp(1);
>> >
>>> On 08.05.15 at 11:07, wrote:
> @@ -101,6 +101,12 @@ static void __init parse_iommu_param(char *s)
> if ( iommu_intremap == 0 )
> iommu_intpost = 0;
> }
> +else if ( !strcmp(s, "intpost") )
> +{
> +iommu_intpost = val;
> +
>>> On 08.05.15 at 11:07, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1664,9 +1664,20 @@ static void __vmx_deliver_posted_interrupt(struct vcpu
> *v)
>
> static void vmx_deliver_posted_intr(struct vcpu *v, u8 vector)
> {
> +int r, sn;
> +
> if (
flight 58299 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58299/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492
test-amd64-i386-xl-qemuu-win
flight 58293 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58293/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect
test-amd64-amd64-pair
>>> On 08.05.15 at 11:07, wrote:
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1711,6 +1711,131 @@ static void vmx_handle_eoi(u8 vector)
> __vmwrite(GUEST_INTR_STATUS, status);
> }
>
> +static void vmx_pi_desc_update(struct vcpu *v, int old_state)
> +{
> +
>>> On 08.05.15 at 11:07, wrote:
> +static inline void setup_posted_irte(
> +struct iremap_entry *new_ire, struct pi_desc *pi_desc, uint8_t gvec)
> +{
> +new_ire->post.urg = 0;
> +new_ire->post.vector = gvec;
> +new_ire->post.pda_l = (((u64)virt_to_maddr(pi_desc)) >>
> +
Hi Dario and Dagaen,
2015-06-09 5:53 GMT-07:00 Dario Faggioli :
>
> Hello Dagaen,
>
> Thanks for doing this. The first question I have is whether you run any
> test/benchmark that you can show the result of here.
Thank you very much Dario for your quick review!
>
> For instance, a few weeks ago,
Is there anywhere I can find in depth and in detail explanation and
description about xen source code and implementation, other than the
comments in the source code?
I need to understand credit scheduler source code line by line for me to be
able to edit it for my needs. A description of what every
On 06/09/2015 03:30 PM, Andrew Cooper wrote:
On 09/06/2015 01:59, Yang Hongyang wrote:
On 06/08/2015 06:15 PM, Andrew Cooper wrote:
On 08/06/15 10:58, Yang Hongyang wrote:
On 06/08/2015 05:46 PM, Andrew Cooper wrote:
On 08/06/15 04:43, Yang Hongyang wrote:
ioreq page contains evtchn wh
On 26/05/2015 21:58, Jan Beulich wrote
> >>> On 13.05.16 at 09:50, wrote:
> > +if (policy->policy == CPUFREQ_POLICY_PERFORMANCE) {
> > +limits.no_turbo = 0;
> > +limits.max_perf_pct = 100;
> > +limits.max_perf = int_tofp(1);
> > +limits.min_perf_pct = 100;
> > +
Thanks for the feedback.
> Thanks for doing this. The first question I have is whether you run any
> test/benchmark that you can show the result of here.
>
> For instance, a few weeks ago, Meng (while trying to do a completely
> different thing) sent here on the list some numbers about the freque
flight 58290 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58290/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl 8 leak-check/basis(8) fail in 58255 pass in 58309-bisect
test-armhf-armhf-xl
flight 58264 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58264/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail pass in 58200
Regressions which are regarded as
flight 58276 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58276/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs.
57908
Regressions wh
Add API for listing assignable USB devices info.
Assignable USB device means the USB device type is assignable and
it's not assigned to any guest yet.
Signed-off-by: Chunyan Liu
---
This could be squashed with previous patch. Split because there is
some dispute on this. If this is acceptable
Add pvusb commands: usb-ctrl-attach, usb-ctrl-detach, usb-list,
usb-attach and usb-detach.
To attach a usb device to guest through pvusb, one could follow
following example:
#xl usb-ctrl-attach test_vm version=1 num_ports=8
#xl usb-list test_vm
will show the usb controllers and port usage und
Add xl usb-assignable-list command to list assignable USB devices.
Assignable USB device means the USB device type is assignable and
it's not assigned to any guest yet.
Signed-off-by: Chunyan Liu
---
Same as "libxl: add libxl_device_usb_assignable_list API" patch,
this patch could be sqaushe
Sysfs file has size=4096 but actual file content is less than that.
Current libxl_read_file_contents will treat it as error when file size
and actual file content differs, so reading sysfs file content with
this function always fails.
Add a new entry libxl_read_sysfs_file_contents to handle sysfs
Add code to support pvusb in domain config file. One could specify
usbctrl and usb in domain's configuration file and create domain,
then usb controllers will be created and usb device would be attached
to guest automatically.
One could specify usb controllers and usb devices in config file
like t
This patch series is to add pvusb toolstack work, supporting hot add|remove
USB device to|from guest and specify USB device in domain configuration file.
Changes to v3:
* add new entry for reading sysfs file contents to get usb device info.
* merge pv|qemu protocol in earlier patches, instead of r
Add pvusb APIs, including:
- attach/detach (create/destroy) virtual usb controller.
- attach/detach usb device
- list usb controller and usb devices
- some other helper functions
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
---
changes:
- make libxl_device_usbctrl_add async, to be
Signed-off-by: Chunyan Liu
Signed-off-by: Simon Cao
Acked-by: Wei Liu
---
tools/libxl/libxl.c | 6 +++---
tools/libxl/libxl_internal.h | 5 +
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9117b01..bd4daea 100644
--- a
flight 58241 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58241/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 5 xen-install fail REGR. vs. 57815
test-amd64-i386-xl-
On Wed, Apr 15, 2015 at 11:14:04PM +0200, Sander Eikelenboom wrote:
>
> Wednesday, April 15, 2015, 10:58:50 PM, you wrote:
>
> >> Hi Konrad,
> >>
> >> xen version is at last changeset 3a28f760508fb35c430edac17a9efde5aff6d1d5
> >> (previous unstable master before the force push which includes
>
This document describes a new capability for VM Introspection, Security and
Privacy in Xen. The new capability is called “altp2m” (short for Alternate p2m)
that is used to provide the ability for Xen to host alternate guest physical
memory domains for a specific guest-domain. This document descr
On 08/06/2015 16:44, Chris (Christopher) Brand wrote:
Hi Julien,
Hi Chris,
My test was limited as I don't have a platform where CNTFRQ/CNTFRQ_EL0 is not
valid. I may have done a mistake in the code.
Understood. That's why I thought it would be worthwhile posting my results :-)
What I see
Hi George,
On 09/06/2015 07:38, George Dunlap wrote:
On 06/09/2015 12:31 PM, Julien Grall wrote:
Hi Olaf,
On 09/06/2015 06:18, Olaf Hering wrote:
On Wed, Jun 03, Julien Grall wrote:
xentrace is not working as we don't have the infrastructure for ARM
in Xen.
Why is that? After a very quick
flight 58263 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58263/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 57312
Tests which are failin
flight 58249 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58249/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492
test-amd64-i386-xl-qemuu-win
flight 58231 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58231/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect
test-amd64-amd64-pair
flight 58255 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58255/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 8 leak-check/basis(8) fail REGR. vs. 56376
Regression
On Mon, Jun 08, 2015 at 10:57:30PM +0200, Laszlo Ersek wrote:
[...]
>
> The issue is real. I've been working on some patches today for this.
> I'll soon send an RFC series.
>
> It's actually easy to *test* this scenario: just create a 128GB or so
> file, with "fallocate", on a sufficiently big fi
On 06/09/15 11:11, Paul Durrant wrote:
>> -Original Message-
>> From: Don Slutz [mailto:dsl...@verizon.com]
>> Sent: 09 June 2015 15:28
>> To: Paul Durrant; Slutz, Donald Christopher; qemu-de...@nongnu.org; xen-
>> de...@lists.xen.org
>> Cc: Michael S. Tsirkin; Stefano Stabellini; Don Slutz
On Mon, 2015-06-08 at 15:55 -0500, Chong Li wrote:
> On Mon, Jun 8, 2015 at 10:56 AM, Dario Faggioli
> > So, Thoughts? What do you think the best way forward could be?
>
> I like option 2 more. But I think we may also need a 'vcpuid' field in
> libxl_sched_params.
>
For sparse array support, yes
>>> On 08.05.15 at 11:07, wrote:
> +void pi_notification_interrupt(struct cpu_user_regs *regs)
static again
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Please give us a chance to respond, it's been only just over a day and
we are all busy with lots of different things.
On Tue, 2015-06-09 at 14:42 +, Jaggi, Manish wrote:
> Hi Ian/Stefano,
> As discussed in the call I have sent the design.
> Didn't got any feedback on this.
>
> Regards,
> Mani
On Tue, 2015-06-09 at 16:06 +0100, Ross Lagerwall wrote:
> After the first call to ExitBootServices(), avoid calling any boot
> services (except GetMemoryMap() and ExitBootServices()) by setting
> setting efi_bs to NULL and halting in blexit(). Only GetMemoryMap() and
> ExitBootServices() are expli
On Tue, 2015-06-09 at 10:12 -0500, Chong Li wrote:
> On Tue, Jun 9, 2015 at 3:01 AM, Dario Faggioli
> wrote:
> How about making
>
> # xl sched-rtds -d vm1
>
> output the per-dom parameters (of vm1), and meanwhile let
>
> # xl sched-rtds -d vm1 -v all
>
> output the per-vcpu parameters (of vm1)
On Tuesday 09 June 2015 08:42 AM, Ian Campbell wrote:
Draft E follows. Also at:
http://xenbits.xen.org/people/ianc/vits/draftE.{pdf,html}
Ian, I have sent a pci passthrough design. It would be good if that can
be linked with this one.
Can I upload the same on xenbits
The major change here ar
>>> On 09.06.15 at 16:58, wrote:
> Hi all
> when there is a page fault the mmu stroes the virtual address that made
> the page fault in the cr2 register right?
> In xen this address is found in page fault handling routine
> do_page_fault in arch/x86/traps.c addr = read_cr2().
> I want to get th
Draft E follows. Also at:
http://xenbits.xen.org/people/ianc/vits/draftE.{pdf,html}
The major change here arises from the realisation that it is not
possible to associate a vPLI with a single pLPI, which has ramifications
for the management of enabling/disabling pLPIs and the handling of
spurious
On Tue, Jun 09, 2015 at 02:49:45PM +0100, Jan Beulich wrote:
> 1: x86/EFI: fix EFI_MEMORY_WP handling
> 2: EFI/early: add /mapbs to map EfiBootServices{Code,Data}
> 3: EFI: support default attributes to map Runtime service areas with none
> given
> 4: x86/EFI: adjust EFI_MEMORY_WP handling for spe
On Tue, Jun 09, 2015 at 04:28:50PM +0100, Jan Beulich wrote:
> >>> On 09.06.15 at 16:08, wrote:
> >> @@ -1220,6 +1224,9 @@ void __init efi_init_memory(void)
> >> #define EFI_MEMORY_RP 0x2000
> >> #define EFI_MEMORY_XP 0x4000
> >> +#define EFI_MEMORY_RO
On 09/06/15 15:59, David Vrabel wrote:
> When sending an event, use a new per-event channel lock to safely
> validate the event channel state.
>
> This new lock must be held when changing event channel state.
>
> To avoid having to take the remote event channel locks when sending to
> an interdomai
On 09/06/15 15:11, Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 09, 2015 at 03:03:18PM +0100, Andrew Cooper wrote:
>> On 09/06/15 14:53, Jan Beulich wrote:
>>> From: Konrad Rzeszutek Wilk
>>>
>>> To help on certain platforms to run.
>>>
>>> Signed-off-by: Konrad Rzeszutek Wilk
>>> Signed-off-by: Ja
On 09/06/15 16:26, Jan Beulich wrote:
On 09.06.15 at 16:08, wrote:
>> On 09/06/15 14:53, Jan Beulich wrote:
>>> From: Konrad Rzeszutek Wilk
>>>
>>> For example on Dell machines we see:
>>>
>>> (XEN) 0fed18000-0fed19fff type=11 attr=8000
>>> (XEN) Unknown cachability for
>>> On 09.06.15 at 16:08, wrote:
>> @@ -1220,6 +1224,9 @@ void __init efi_init_memory(void)
>> #define EFI_MEMORY_RP 0x2000
>> #define EFI_MEMORY_XP 0x4000
>> +#define EFI_MEMORY_RO 0x0002
>> +
>> +#define EFI_MEMORY_NV
>>> On 09.06.15 at 16:08, wrote:
> On 09/06/15 14:53, Jan Beulich wrote:
>> From: Konrad Rzeszutek Wilk
>>
>> For example on Dell machines we see:
>>
>> (XEN) 0fed18000-0fed19fff type=11 attr=8000
>> (XEN) Unknown cachability for MFNs 0xfed18-0xfed19
>>
>> Let's allow them to
>>> On 09.06.15 at 16:03, wrote:
> On 09/06/15 14:53, Jan Beulich wrote:
>> From: Konrad Rzeszutek Wilk
>>
>> To help on certain platforms to run.
>>
>> Signed-off-by: Konrad Rzeszutek Wilk
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.
> -Original Message-
> From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz]
> Sent: 09 June 2015 15:44
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH 00/17] x86/hvm: I/O emulation cleanup and
> fix
>
> Il 08/06/2015 16:33, Paul Durrant ha scritto:
> > Th
>>> On 08.05.15 at 11:07, wrote:
> @@ -3262,6 +3271,28 @@ void vmx_vmenter_helper(const struct cpu_user_regs
> *regs)
> }
>
> /*
> + * Handle VT-d posted-interrupt when VCPU is blocked.
> + */
> +void pi_wakeup_interrupt(struct cpu_user_regs *regs)
static (and perhaps move it up so you don't
On 09/06/15 16:08, Andrew Cooper wrote:
> On 09/06/15 15:59, David Vrabel wrote:
>> By keeping a count of the number of currently valid event channels,
>> port_is_valid() can be simplified.
>>
>> d->valid_evtchns can also be tested without holding d->event_lock which
>> will be useful later on.
[..
> -Original Message-
> From: Don Slutz [mailto:dsl...@verizon.com]
> Sent: 09 June 2015 15:28
> To: Paul Durrant; Slutz, Donald Christopher; qemu-de...@nongnu.org; xen-
> de...@lists.xen.org
> Cc: Michael S. Tsirkin; Stefano Stabellini; Don Slutz
> Subject: Re: [PATCH v2 4/4] xen: Fix map/u
On Tue, Jun 9, 2015 at 3:01 AM, Dario Faggioli
wrote:
> On Mon, 2015-06-08 at 16:18 -0500, Chong Li wrote:
>> On Mon, Jun 8, 2015 at 11:21 AM, Dario Faggioli
>> wrote:
>> > On Mon, 2015-05-25 at 19:11 -0500, Chong Li wrote:
>
>> > I appreciate just now that this probably affect other bits of the
>>> On 08.05.15 at 11:07, wrote:
> This patch defines two per-cpu variables:
>
> blocked_vcpu:
> A list storing the vCPUs which were blocked on this pCPU.
>
> blocked_vcpu_lock:
> The spinlock to protect blocked_vcpu.
>
> Signed-off-by: Feng Wu
It doesn't look like this is worth a separate pa
On 06/09/15 10:27, Michael S. Tsirkin wrote:
> On Tue, Jun 09, 2015 at 02:14:29PM +, Paul Durrant wrote:
>>> -Original Message-
>>> From: Michael S. Tsirkin [mailto:m...@redhat.com]
>>> Sent: 09 June 2015 13:30
>>> To: Paul Durrant
>>> Cc: Don Slutz; qemu-de...@nongnu.org; xen-devel@lis
On 09/06/15 15:59, David Vrabel wrote:
> By keeping a count of the number of currently valid event channels,
> port_is_valid() can be simplified.
>
> d->valid_evtchns can also be tested without holding d->event_lock which
> will be useful later on.
>
> Signed-off-by: David Vrabel
> ---
> xen/comm
>>> On 08.05.15 at 11:07, wrote:
> This patch adds a new per-vCPU tasklet to wakeup the blocked
> vCPU. It can be used in the case vcpu_unblock cannot be called
> directly. This tasklet will be used in later patch in this
> series.
>
> Signed-off-by: Feng Wu
> ---
> xen/common/domain.c | 11
After the first call to ExitBootServices(), avoid calling any boot
services (except GetMemoryMap() and ExitBootServices()) by setting
setting efi_bs to NULL and halting in blexit(). Only GetMemoryMap() and
ExitBootServices() are explicitly allowed to be called after the first
call to ExitBootServic
>>> On 08.05.15 at 11:07, wrote:
> +static bool_t pi_find_dest_vcpu(struct domain *d, uint8_t dest_id,
> +uint8_t dest_mode, uint8_t delivery_mode,
> +uint8_t gvec, struct vcpu **dest_vcpu)
> +{
> +struct vcpu *v, **dest_vcpu_arra
The event channel lock is no longer required to check if the port is
valid.
Signed-off-by: David Vrabel
---
xen/common/event_channel.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 71747d1..7ab0516 100644
flight 58230 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58230/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 11 guest-start fail REGR. vs. 53854
test-amd64-amd64-libvirt
The per-domain event channel lock may suffer from contention. Add it to
the set of locks to be profiled when lock profiling is enabled.
Signed-off-by: David Vrabel
---
xen/common/event_channel.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/event_channel.c b/
The number of struct evtchn in a page must be a power of two. Under
some workloads performance is improved slightly by padding struct
evtchn to 64 bytes (a cache line), thus putting the per-channel locks
into their own cache line.
This does not decrease the number of struct evtchn's per-page.
Si
By keeping a count of the number of currently valid event channels,
port_is_valid() can be simplified.
d->valid_evtchns can also be tested without holding d->event_lock which
will be useful later on.
Signed-off-by: David Vrabel
---
xen/common/event_channel.c |3 +++
xen/include/xen/event.h
The per-domain event channel lock limits scalability when many VCPUs
are trying to send interdomain events. A per-channel lock is
introduced eliminating any lock contention when sending an event.
See this graph for the performance improvements:
http://xenbits.xen.org/people/dvrabel/evtchn-scal
When sending an event, use a new per-event channel lock to safely
validate the event channel state.
This new lock must be held when changing event channel state.
To avoid having to take the remote event channel locks when sending to
an interdomain event channel, the local and remote channel locks
We're going to want to free an event channel from two places. Factor out
the code into a free_evtchn() function.
Signed-off-by: David Vrabel
---
xen/common/event_channel.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/xen/common/event_channel.c b/xe
Hi all
when there is a page fault the mmu stroes the virtual address that made
the page fault in the cr2 register right?
In xen this address is found in page fault handling routine
do_page_fault in arch/x86/traps.c addr = read_cr2().
I want to get the page table entry associated with this virtu
Stefano Stabellini writes ("Re: [PATCH v2 5/5] libxl: spawns two QEMUs for HVM
guests"):
> That is of great help, but this code is quite complex and I don't
> understand it. I tried to complete the missing bits but I think I ended
> up with something quite far from what you had in mind. At least i
Il 08/06/2015 16:33, Paul Durrant ha scritto:
This patch series re-works much of the code involved in emulation of port
and memory mapped I/O for HVM guests.
The code has become very convoluted and, at least by inspection, certain
emulations will apparently malfunction.
The series is broken dow
Hi Ian/Stefano,
As discussed in the call I have sent the design.
Didn't got any feedback on this.
Regards,
Manish Jaggi
From: xen-devel-boun...@lists.xen.org on
behalf of Manish Jaggi
Sent: Monday, June 8, 2015 12:52:55 AM
To: xen-devel@lists.xen.org; I
>>> On 08.05.15 at 11:07, wrote:
> +bool_t pi_update_irte(struct vcpu *v, struct pirq *pirq, uint8_t gvec)
Without seeing the caller right away it's hard to judge, but generally I'd
prefer functions to return -E... values as error indicators, i.e.
> +{
> +struct irq_desc *desc;
> +struct
flight 58228 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58228/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 15
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 5
On 06/09/15 10:03, Paul Durrant wrote:
>> -Original Message-
>> From: Don Slutz [mailto:dsl...@verizon.com]
>> Sent: 09 June 2015 14:51
>> To: Paul Durrant; Slutz, Donald Christopher; qemu-de...@nongnu.org; xen-
>> de...@lists.xen.org
>> Cc: Michael S. Tsirkin; Stefano Stabellini; Don Slutz
On Tue, Jun 09, 2015 at 04:07:33PM +0200, Roger Pau Monné wrote:
> El 09/06/15 a les 15.39, Konrad Rzeszutek Wilk ha escrit:
> > On Tue, Jun 09, 2015 at 08:52:53AM +, Paul Durrant wrote:
> >>> -Original Message-
> >>> From: Bob Liu [mailto:bob@oracle.com]
> >>> Sent: 09 June 2015 09
On Tue, Jun 09, 2015 at 02:14:29PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > Sent: 09 June 2015 13:30
> > To: Paul Durrant
> > Cc: Don Slutz; qemu-de...@nongnu.org; xen-devel@lists.xen.org; Stefano
> > Stabellini
> > Subject:
>>> On 08.05.15 at 11:07, wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -289,7 +289,7 @@ struct dma_pte {
> /* interrupt remap entry */
> struct iremap_entry {
>union {
> -u64 lo_val;
> +struct { u64 lo, hi; };
> struct {
>
On Tue, Jun 09, 2015 at 10:08:56AM -0400, Konrad Rzeszutek Wilk wrote:
> .. ..snip..
> > @@ -1220,6 +1224,9 @@ void __init efi_init_memory(void)
> > prot |= _PAGE_PAT | MAP_SMALL_PAGES;
> > else if ( desc->Attribute & (EFI_MEMORY_UC | EFI_MEMORY_UCE) )
> > prot |=
>>> On 08.05.15 at 11:07, wrote:
> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
> @@ -28,6 +28,9 @@
> #include
> #include
> #include
> +#include
> +
> +extern uint8_t posted_intr_vector;
>
> typedef union {
> struct {
> @@ -125,6 +128,22 @@ stati
On Tue, 9 Jun 2015, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH v2 5/5] libxl: spawns two QEMUs for HVM
> guests"):
> > The spawn_outcome function does something like this:
> >
> >int worst_rc = 0;
> >
> >libxl_report_child_exitstatus(...)
> >dcs->qemus[myself]->
>>> On 08.05.15 at 11:07, wrote:
> Extend struct pi_desc according to VT-d Posted-Interrupts Spec.
>
> Signed-off-by: Feng Wu
> ---
> xen/include/asm-x86/hvm/vmx/vmcs.h | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h
On 09/06/15 14:54, Jan Beulich wrote:
> That flag now means cachability rather than protection, and a new flag
> EFI_MEMORY_RO got added in its place.
>
> Signed-off-by: Jan Beulich
This matches my reading of the 2.5 spec.
Reviewed-by: Andrew Cooper
>>> On 08.05.15 at 11:07, wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -2044,6 +2044,7 @@ static int init_vtd_hw(void)
> if ( ioapic_to_iommu(IO_APIC_ID(apic)) == NULL )
> {
> iommu_intremap = 0;
> +
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: 09 June 2015 13:30
> To: Paul Durrant
> Cc: Don Slutz; qemu-de...@nongnu.org; xen-devel@lists.xen.org; Stefano
> Stabellini
> Subject: Re: [PATCH v2 0/4] Fix device listener interface for PCI to PCI
> bridges
On Tue, Jun 09, 2015 at 03:03:18PM +0100, Andrew Cooper wrote:
> On 09/06/15 14:53, Jan Beulich wrote:
> > From: Konrad Rzeszutek Wilk
> >
> > To help on certain platforms to run.
> >
> > Signed-off-by: Konrad Rzeszutek Wilk
> > Signed-off-by: Jan Beulich
> >
> > --- a/xen/arch/x86/efi/efi-boot.
>>> On 08.05.15 at 11:07, wrote:
> @@ -51,6 +52,7 @@ bool_t __read_mostly iommu_passthrough;
> bool_t __read_mostly iommu_snoop = 1;
> bool_t __read_mostly iommu_qinval = 1;
> bool_t __read_mostly iommu_intremap = 1;
> +bool_t __read_mostly iommu_intpost = 0;
Pointless initializer.
> @@ -94,7
On 09/06/15 14:53, Jan Beulich wrote:
> From: Konrad Rzeszutek Wilk
>
> For example on Dell machines we see:
>
> (XEN) 0fed18000-0fed19fff type=11 attr=8000
> (XEN) Unknown cachability for MFNs 0xfed18-0xfed19
>
> Let's allow them to be mapped as UC.
>
> We also alter the 'efi
. ..snip..
> @@ -1220,6 +1224,9 @@ void __init efi_init_memory(void)
> prot |= _PAGE_PAT | MAP_SMALL_PAGES;
> else if ( desc->Attribute & (EFI_MEMORY_UC | EFI_MEMORY_UCE) )
> prot |= _PAGE_PWT | _PAGE_PCD | MAP_SMALL_PAGES;
> +else if ( efi_bs_revision >=
El 09/06/15 a les 15.39, Konrad Rzeszutek Wilk ha escrit:
> On Tue, Jun 09, 2015 at 08:52:53AM +, Paul Durrant wrote:
>>> -Original Message-
>>> From: Bob Liu [mailto:bob@oracle.com]
>>> Sent: 09 June 2015 09:50
>>> To: Bob Liu
>>> Cc: xen-devel@lists.xen.org; David Vrabel; just...@
On 09/06/15 14:53, Jan Beulich wrote:
> From: Konrad Rzeszutek Wilk
>
> To help on certain platforms to run.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -148,12 +148,16 @@ static void __init
> -Original Message-
> From: Don Slutz [mailto:dsl...@verizon.com]
> Sent: 09 June 2015 14:51
> To: Paul Durrant; Slutz, Donald Christopher; qemu-de...@nongnu.org; xen-
> de...@lists.xen.org
> Cc: Michael S. Tsirkin; Stefano Stabellini; Don Slutz
> Subject: Re: [PATCH v2 4/4] xen: Fix map/u
On 06/09/15 09:55, Paul Durrant wrote:
>> -Original Message-
>> From: Don Slutz [mailto:dsl...@verizon.com]
>> Sent: 09 June 2015 14:53
>> To: Paul Durrant; Slutz, Donald Christopher; qemu-de...@nongnu.org; xen-
>> de...@lists.xen.org
>> Cc: Michael S. Tsirkin; Stefano Stabellini; Don Slutz
On 09/06/15 14:52, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
>
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1195,7 +1195,7 @@ void __init efi_init_memory(void)
> }
>
> if ( desc->Attribute & EFI_MEMORY_WP )
> -
> -Original Message-
> From: Don Slutz [mailto:dsl...@verizon.com]
> Sent: 09 June 2015 14:53
> To: Paul Durrant; Slutz, Donald Christopher; qemu-de...@nongnu.org; xen-
> de...@lists.xen.org
> Cc: Michael S. Tsirkin; Stefano Stabellini; Don Slutz
> Subject: Re: [PATCH v2 2/4] Extend device
That flag now means cachability rather than protection, and a new flag
EFI_MEMORY_RO got added in its place.
Signed-off-by: Jan Beulich
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -32,6 +32,8 @@
/* Using SetVirtualAddressMap() is incompatible with kexec: */
#undef USE_SET_VIRTUA
From: Konrad Rzeszutek Wilk
For example on Dell machines we see:
(XEN) 0fed18000-0fed19fff type=11 attr=8000
(XEN) Unknown cachability for MFNs 0xfed18-0xfed19
Let's allow them to be mapped as UC.
We also alter the 'efi-rs' to be 'efi=rs' or 'efi=no-rs'.
Signed-off-by: Ko
On 06/09/15 05:08, Paul Durrant wrote:
>> -Original Message-
>> From: Don Slutz [mailto:dsl...@verizon.com]
>> Sent: 08 June 2015 22:19
>> To: qemu-de...@nongnu.org; xen-devel@lists.xen.org
>> Cc: Michael S. Tsirkin; Paul Durrant; Stefano Stabellini; Don Slutz; Don
>> Slutz
>> Subject: [PA
From: Konrad Rzeszutek Wilk
To help on certain platforms to run.
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -148,12 +148,16 @@ static void __init efi_arch_process_memo
switch ( desc->Type )
1 - 100 of 197 matches
Mail list logo
