On Mon, Jun 29, 2015 at 5:53 PM, Ian Campbell wrote:
> On Mon, 2015-06-22 at 17:31 +0530, vijay.kil...@gmail.com wrote:
>> +static int vgic_its_process_mapvi(struct vcpu *v, struct vgic_its *vits,
>> + its_cmd_block *virt_cmd)
>> +{
>> +struct vitt entry;
>> +
flight 59037 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59037/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866
build-i386-rumpuserxe
flight 59025 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59025/
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
Reg
Hi Dario,
[Since I have commented on this thread in previous email, I just
top-post it for reminder.]
Just in case, this email is out of your radar... :-)
I had discussed this patch with Dagaen as shown in
http://www.gossamer-threads.com/lists/xen/devel/386651
You don't need any detailed commen
flight 59024 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59024/
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
On 07/02/2015 06:41 PM, George Dunlap wrote:
On Mon, Jun 29, 2015 at 2:36 PM, Juergen Gross wrote:
On 06/29/2015 03:22 PM, George Dunlap wrote:
I think in an ideal world the toolstack will use the kernel backend if
it's available, and fall back to a qemu backend if it's not available.
In ca
On 06/30/2015 05:45 PM, Yang Hongyang wrote:
On 06/30/2015 12:07 AM, Ian Campbell wrote:
On Thu, 2015-06-25 at 14:25 +0800, Yang Hongyang wrote:
ITYM "handling" in the subject. And perhaps "change" rather than "fix"?
If the err is RECORD_NOT_PROCESSED, and it is an optional record,
restor
Hi Roger,
This seems to be a PVH guest, but IIRC a PVH guest should explicitly
specify 'pvh' in the config, maybe I'm wrong or did I miss some background?
Are there any meterial about this?
On 07/01/2015 10:45 PM, Roger Pau Monne wrote:
This series is split in the following order:
- Patche
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Thursday, July 02, 2015 9:00 PM
> To: Dario Faggioli
> Cc: Wu, Feng; Tian, Kevin; k...@xen.org; george.dun...@eu.citrix.com;
> xen-devel@lists.xen.org; jbeul...@suse.com; Zhang, Yang Z
> Subject: Re: [Xe
flight 59023 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59023/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 9 windows-installfail REGR. vs. 59010
Regressions which a
> On Jul 2, 2015, at 11:49 AM, Luis R. Rodriguez wrote:
>
> On Sat, Jun 27, 2015 at 08:00:48AM +1000, Benjamin Herrenschmidt wrote:
>> On Fri, 2015-06-26 at 16:24 +, Casey Leedom wrote:
>>> Thanks for looking into this Ben. As it stands now, it seems as
>>> if Write Combined mappings simpl
On Thu, 2015-07-02 at 20:49 +0200, Luis R. Rodriguez wrote:
> > The question then is what is "the right thing". In the powerpc case,
> > we'll have a non-garded mapping, which means we also get no ordering
> > between load and stores.
>
> I don't follow, you *ordering* between load and stores for
On Wed, Jul 1, 2015 at 10:42 AM, Dario Faggioli
wrote:
> Hey,
>
> I know Wei is away, so I'll try to find the time to look at this myself,
> but I figured I'll let know about it, in case someone has obvious (or
> not :-D) ideas.
>
> I think I'm facing a bug that prevents creating PV guests with a
flight 59018 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59018/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 58981
Regressions which ar
To deal with xen_host_pci_[set|get]_ functions returning error values
and clearing ourselves in the init function we should make the
.exit (xen_pt_unregister_device) function be idempotent in case
the generic code starts calling .exit (or for fun does it before
calling .init!).
Signed-off-by: Konr
During init time we treat the dev.config area as a cache
of the host view. However during execution time we treat it
as guest view (by the generic PCI API). We need to sync Xen's
code to the generic PCI API view. This is the first step
by replacing all of the code that uses dev.config or
pci_get_[b
We do not want to have two entries to cache the guest configuration
registers: XenPTReg->data and dev.config. Instead we want to use
only the dev.config.
To do without much complications we rip out the ->data field
and replace it with an pointer to the dev.config. This way we
have the type-checkin
and if we have failures we call xen_pt_destroy introduced in
'xen/pt: Move bulk of xen_pt_unregister_device in its own routine.'
and free all of the allocated structures.
Acked-by: Stefano Stabellini
Signed-off-by: Konrad Rzeszutek Wilk
---
hw/xen/xen_pt.c | 24
1 file
For a passthrough device we maintain a state of emulated
registers value contained within d->config. We also consult
the host registers (and apply ro and write masks) whenever
the guest access the registers. This is done in xen_pt_pci_write_config
and xen_pt_pci_read_config.
Also in this picture w
Since RFC [https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg07350.html]
- Added Acks
- Fixed bugs
This patchset is dependent on the "Cleanups + various fixes due to libxl ABI
+ more logging on errors."
(http://lists.xen.org/archives/html/xen-devel/2015-07/msg00431.html)
just poste
Otherwise we get:
xen_pt_config_reg_init: Offset 0x0004 mismatch! Emulated=0x,
host=0x2300017, syncing to 0x2300014.
xen_pt_config_reg_init: Error: Offset 0x0004:0x2300014 expands past register
size(2)!
which is not surprising. We read the value as an 32-bit (from host),
then operate it as
It should never happen, but in case it does (an developer adds
a new register and the 'init_val' expands past the register
size) we want to report. The code will only write up to
reg->size so there is no runtime danger of the register spilling
across other ones - however to catch this sort of thing
This way we can call it if we fail during init.
This code movement introduces no changes.
Acked-by: Stefano Stabellini
Signed-off-by: Konrad Rzeszutek Wilk
---
hw/xen/xen_pt.c | 119 +---
1 file changed, 62 insertions(+), 57 deletions(-)
dif
To help with troubleshooting in the field.
Acked-by: Stefano Stabellini
Signed-off-by: Konrad Rzeszutek Wilk
---
hw/xen/xen_pt_config_init.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 0a710a2..a2af415 100644
--- a
We seem to only use these functions when de-activating the
MSI - so just log errors.
Reviewed-by: Stefano Stabellini
Signed-off-by: Konrad Rzeszutek Wilk
---
hw/xen/xen_pt_msi.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/
Hey!
since RFC [https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg07326.html]
- Added Acks
- Followed 'xen: Print and use errno where applicable.' suggestion by Stefano
and added a wrapper.
As I am in the process of syncing the 'dev.config' and Xen's internal
cache of the PCI config s
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
---
hw/xen/xen_pt_config_init.c | 6 +++---
1 file changed, 3 insertions(+), 3
As we do not use it outside our code.
Reviewed-by: Stefano Stabellini
Signed-off-by: Konrad Rzeszutek Wilk
---
hw/xen/xen_pt.h | 1 -
hw/xen/xen_pt_msi.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 393f36c..09358b1 100644
---
However the init routines assume that on errors the return
code is -1 (as the libxc API is) - while those xen_host_* routines follow
another paradigm - negative errno on return, 0 on success.
Reviewed-by: Stefano Stabellini
Signed-off-by: Konrad Rzeszutek Wilk
---
hw/xen/xen_pt.c | 2 +-
1 file
It has changed but the comments still refer to the old names.
Reviewed-by: Stefano Stabellini
Signed-off-by: Konrad Rzeszutek Wilk
---
hw/xen/xen_pt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index ed5fcae..706e3d9 100644
--- a/hw
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
is either 0 or an positive value.
Since we could be runnin
If XEN_PT_LOGGING_ENABLED is enabled the XEN_PT_LOG macros start
using the first argument. Which means if within the function there
is only one user of the argument ('d') and XEN_PT_LOGGING_ENABLED
is not set, we get compiler warnings. This is not the case now
but with the "xen/pt: Use xen_host_pci
On 07/01/2015 02:09 PM, Ed White wrote:
From: Ravi Sahita
Signed-off-by: Ravi Sahita
Acked-by: Daniel De Graaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
> > @@ -858,15 +863,20 @@ static void xen_pt_unregister_device(PCIDevice *d)
> > machine_irq, errno);
> > }
> > }
> > +s->machine_irq = 0;
> > }
> >
> > /* delete all emulated config registers */
> > xen_pt_config_delete(s);
On Sat, Jun 27, 2015 at 08:00:48AM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2015-06-26 at 16:24 +, Casey Leedom wrote:
> > Thanks for looking into this Ben. As it stands now, it seems as
> > if Write Combined mappings simply aren't supported and/or all
> > driver writers trying to util
flight 59016 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59016/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 58988
test-amd64-i386-xl-qemuu-win7-amd64 1
El 02/07/15 a les 19.42, George Dunlap ha escrit:
> There are a lot of paths through
> libxl__device_disk_local_initiate_attach(), but they all really boil
> down to one thing: Can we just access the file directly, or do we need
> to attach it?
>
> The requirements for direct access are fairly sim
There are a lot of paths through
libxl__device_disk_local_initiate_attach(), but they all really boil
down to one thing: Can we just access the file directly, or do we need
to attach it?
The requirements for direct access are fairly simple:
* Is this local (as opposed to a driver domain)?
* Is thi
On 02/07/15 18:14, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: 02 July 2015 18:11
>> To: Paul Durrant; xen-de...@lists.xenproject.org
>> Cc: Keir (Xen.org); Jan Beulich
>> Subject: Re: [PATCH v5 09/16] x86/hvm: limit reps to a
flight 59020 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59020/
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 07/02/2015 12:25 PM, David Vrabel wrote:
On 02/07/15 15:53, Boris Ostrovsky wrote:
I haven't posted Linux part of PV(H) VPMU support in a while but now
that (hopefully) the hypervisor part is getting close to be done I
think it's time to post it again.
Remind me once the hypervisor bits are
On Tue, Jun 30, 2015 at 6:46 PM, Ian Jackson wrote:
> osstest's test coverage is improving, which means that the tests keep
> taking longer. Even with ongoing expansion of the test facility, the
> overall time between a bad push and getting results can be quite long
> - currently perhaps 12-36h d
On 07/02/2015 12:21 PM, David Vrabel wrote:
On 02/07/15 15:53, Boris Ostrovsky wrote:
Map shared data structure that will hold CPU registers, VPMU context,
V/PCPU IDs of the CPU interrupted by PMU interrupt. Hypervisor fills
this information in its handler and passes it to the guest for further
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 02 July 2015 18:11
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Keir (Xen.org); Jan Beulich
> Subject: Re: [PATCH v5 09/16] x86/hvm: limit reps to avoid the need to
> handle retry
>
> On 30/06
Robert Hu writes ("Re: [OSSTEST RFC PATCH 0/4] Nested job execution
infrastructure"):
> On Tue, 2015-06-30 at 17:36 +0100, Ian Jackson wrote:
> > If you like the look of this approach, please feel free to fold these
> > patches into your own series at the appropriate point (retaining my
> > From:
Break out the function find_guests from what was
fetch_logs_host_guests, and have it save its results in the @guests
global.
We do this soon because in the next patch we are going to want to
do something to each guest before we call serial_fetch_logs.
The loop containing fetch_logs_guest is now i
I discovered that xenctx was not being run any more. These 4 patches
fix it, and also arrange to run it sooner.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 30/06/15 14:05, Paul Durrant wrote:
> @@ -235,7 +219,7 @@ static int hvmemul_do_io_buffer(
>
> BUG_ON(buffer == NULL);
>
> -rc = hvmemul_do_io(is_mmio, addr, reps, size, dir, df, 0,
> +rc = hvmemul_do_io(is_mmio, addr, *reps, size, dir, df, 0,
> (uintptr_
The regexp was wrong, resulting in the last digit of the memory being
mistaken for the number of vcpus (!)
The only consumer of this is ts-logs-capture.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/TestSuppo
xenctx is now in /usr/local/lib/xen/bin/xenctx.
^^
Find it by setting PATH in the shell command.
Signed-off-by: Ian Jackson
---
ts-logs-capture |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/ts-logs-capture b/ts-logs-capture
index 2498416..1
Break fetch_xenctx_guest out into its own function, and run it before
serial_fetch_logs.
This is relevant because serial_fetch_logs sends the Xen debug keys,
which might dislodge a stuck guest - and, if it does, we would like to
have captured the stuck state with xenctx, rather than the unstuck
on
On Thu, 2 Jul 2015, Julien Grall wrote:
> Hi,
>
> Ping?
>
The patch looks very nice.
Reviewed-by: Stefano Stabellini
>
> On 17/06/15 14:58, Julien Grall wrote:
> > Currently, the grant table region is hardcoded per-platform. When a new
> > board is coming up, we have to check the spec in ord
On 30/06/15 14:05, Paul Durrant wrote:
> @@ -275,7 +275,8 @@ static uint8_t stdvga_mem_readb(uint64_t addr)
> return ret;
> }
>
> -static uint64_t stdvga_mem_read(uint64_t addr, uint64_t size)
> +static int stdvga_mem_read(const struct hvm_io_handler *handler,
> +
On 30/06/15 14:05, Paul Durrant wrote:
> This patch re-works the dpci portio intercepts so that they can be unified
> with standard portio handling thereby removing a substantial amount of
> code duplication.
>
> Signed-off-by: Paul Durrant
> Cc: Keir Fraser
> Cc: Jan Beulich
> Cc: Andrew Cooper
On 30/06/15 14:05, Paul Durrant wrote:
> When memory mapped I/O is range checked by internal handlers, the length
> of the access should be taken into account.
>
> Signed-off-by: Paul Durrant
> Cc: Keir Fraser
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> xen/arch/x86/hvm/intercept.c | 22 ++
On Mon, Jun 29, 2015 at 2:36 PM, Juergen Gross wrote:
> On 06/29/2015 03:22 PM, George Dunlap wrote:
>> I think in an ideal world the toolstack will use the kernel backend if
>> it's available, and fall back to a qemu backend if it's not available.
>
>
> In case the performance is regarded to be s
flight 59015 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59015/
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
Tests which are failin
Ian Campbell writes ("[PATCH OSSTEST v3] mg-all-branch-statuses: Show how up to
date each branch is"):
> Using report_find_push_age_info allows us to provide counts of
> attempts since the last baseline on current tip as well as the first
> attempt of each of those.
>
> Since everything serialise
On 30/06/15 14:05, Paul Durrant wrote:
> -bool_t hvm_mmio_internal(paddr_t gpa)
> +static int hvm_portio_read(const struct hvm_io_handler *handler,
> + uint64_t addr,
> + uint32_t size,
> + uint64_t *data)
> {
> -str
On 02/07/15 13:59, Ian Campbell wrote:
> On Thu, 2015-07-02 at 18:14 +0530, Vijay Kilari wrote:
>> On Thu, Jul 2, 2015 at 6:05 PM, Ian Campbell wrote:
>>> On Thu, 2015-07-02 at 17:51 +0530, Vijay Kilari wrote:
On Mon, Jun 29, 2015 at 5:29 PM, Ian Campbell
wrote:
> On Tue, 2015-06-2
Hi,
On 02/07/15 14:18, Vitaly Kuznetsov wrote:
> 'pfn' and 'start_pfn' are ambiguous, both these functions expect GFNs as
> input.
>
> On x86 the interface of p2m_set_mem_access() in p2m.c doesn't match the
> declaration in p2m-common.h as 'pfn' is being used instead of 'start_pfn'.
>
> On ARM
Euan Harris writes ("[PATCH] doc: Fix nonexistent error code in
libxl_event_check example"):
> Fix example code in comment.libxl_event_check() can return
> ERROR_NOT_READY; LIBXL_NOT_READY does not exist.
>
> Signed-off-by: Euan Harris
Acked-by: Ian Jackson
Committed-by: Ian Jackson
___
On 02/07/15 15:53, Boris Ostrovsky wrote:
> I haven't posted Linux part of PV(H) VPMU support in a while but now
> that (hopefully) the hypervisor part is getting close to be done I
> think it's time to post it again.
Remind me once the hypervisor bits are in and I can shovel this in
(hopefully fo
On 02/07/15 15:53, Boris Ostrovsky wrote:
> Add PMU emulation code that runs when we are processing a PMU interrupt.
> This code will allow us not to trap to hypervisor on each MSR/LVTPC access
> (of which there may be quite a few in the handler).
Reviewed-by: David Vrabel
David
___
On 02/07/15 15:53, Boris Ostrovsky wrote:
> Map shared data structure that will hold CPU registers, VPMU context,
> V/PCPU IDs of the CPU interrupted by PMU interrupt. Hypervisor fills
> this information in its handler and passes it to the guest for further
> processing.
>
> Set up PMU VIRQ.
>
>
On 02/07/15 15:53, Boris Ostrovsky wrote:
> Set Xen's PMU mode via /sys/hypervisor/pmu/pmu_mode. Add XENPMU hypercall.
Reviewed-by: David Vrabel
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Thu, Jul 2, 2015 at 5:01 PM, Dario Faggioli
wrote:
> On Thu, 2015-07-02 at 16:24 +0100, George Dunlap wrote:
>> On Thu, Jun 25, 2015 at 1:15 PM, Dario Faggioli
>> wrote:
>> > Ideally, the pCPUs that are 'free', i.e., not assigned
>> > to any cpupool, should not be considred by the scheduler
>>
On 07/02/2015 02:18 PM, Vitaly Kuznetsov wrote:
> 'pfn' and 'start_pfn' are ambiguous, both these functions expect GFNs as
> input.
>
> On x86 the interface of p2m_set_mem_access() in p2m.c doesn't match the
> declaration in p2m-common.h as 'pfn' is being used instead of 'start_pfn'.
>
> On ARM
On 02/07/15 16:55, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: 02 July 2015 16:38
>> To: Paul Durrant; xen-de...@lists.xenproject.org
>> Cc: Keir (Xen.org); Jan Beulich
>> Subject: Re: [PATCH v5 02/16] x86/hvm: remove multiple
On Thu, 2015-07-02 at 16:24 +0100, George Dunlap wrote:
> On Thu, Jun 25, 2015 at 1:15 PM, Dario Faggioli
> wrote:
> > Ideally, the pCPUs that are 'free', i.e., not assigned
> > to any cpupool, should not be considred by the scheduler
> > for load balancing or anything. In Credit1, we fail at
> >
No longer send reports, or copies, to named individuals. Instead,
send all output to 1. appropriate development mailing lists 2. the new
osstest-admin@xenproject administrator alias, and 3. Bcc the new
osstest-output list.
Bisection progress emails go only to osstest-output. In this case we
prov
On 06/26/2015 05:18 PM, Dario Faggioli wrote:
> Hi everyone,
>
> This series is the follow up of this proposal and conversation:
> http://lists.xen.org/archives/html/xen-devel/2015-05/msg02874.html
>
> Let me quote this (again), from 2006:
> git show db51cd09d37ea44b126bb259f9392248afd768e6
>
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 02 July 2015 16:55
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Keir (Xen.org); Jan Beulich
> Subject: Re: [PATCH v5 04/16] x86/hvm: restrict port numbers to uint16_t
> and sizes to unsigned in
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 02 July 2015 16:38
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Keir (Xen.org); Jan Beulich
> Subject: Re: [PATCH v5 02/16] x86/hvm: remove multiple open coded
> 'chunking' loops
>
> On 30/06/
On 30/06/15 14:05, Paul Durrant wrote:
> diff --git a/xen/include/asm-x86/hvm/io.h b/xen/include/asm-x86/hvm/io.h
> index d1d79dc..1ed0c13 100644
> --- a/xen/include/asm-x86/hvm/io.h
> +++ b/xen/include/asm-x86/hvm/io.h
> @@ -41,12 +41,12 @@ typedef int (*hvm_mmio_write_t)(struct vcpu *v,
> typede
On 30/06/15 14:05, Paul Durrant wrote:
> ...from unsigned long to unsigned int
>
> A 64-bit length is not necessary, 32 bits is enough.
>
> Signed-off-by: Paul Durrant
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http:
On Thu, Jun 25, 2015 at 1:15 PM, Dario Faggioli
wrote:
> and of (almost every) direct use of cpupool_online_cpumask().
>
> In fact, what we really want for the most of the times,
> is the set of valid pCPUs of the cpupool a certain domain
> is part of. Furthermore, in case it's called with a NULL
On 30/06/15 14:05, Paul Durrant wrote:
> ...in hvmemul_read/write()
>
> Add hvmemul_phys_mmio_access() and hvmemul_linear_mmio_access() functions
> to reduce code duplication.
>
> NOTE: This patch also introduces a change in 'chunking' around a page
> boundary. Previously (for example) an 8 b
Hi,
Ping?
Regards,
On 17/06/15 14:58, Julien Grall wrote:
> Currently, the grant table region is hardcoded per-platform. When a new
> board is coming up, we have to check the spec in order to find a space
> in the memory layout free. Depending on the platform it may be tedious.
>
> A good candi
Ian Campbell writes ("Re: [PATCH OSSTEST v2] mg-all-branch-statuses: Show how
up to date each branch is"):
> On Wed, 2015-07-01 at 15:35 +0100, Ian Jackson wrote:
> > It's not so much unknown as n/a.
>
> Do you prefer the script to say "n/a" rather than nothing?
Midly, I think. This is all bike
Roger Pau Monne writes ("[PATCH] osstest: install libnl3 packages"):
> Install the libnl3 packages needed by the remus code. Those are available on
> both Wheezy and Jessie, although the Wheezy ones are too old.
This patch implicitly drops support for lenny and squeeze. I think
you should mention
On Thu, Jun 25, 2015 at 1:15 PM, Dario Faggioli
wrote:
> Ideally, the pCPUs that are 'free', i.e., not assigned
> to any cpupool, should not be considred by the scheduler
> for load balancing or anything. In Credit1, we fail at
> this, because of how we use cpupool_scheduler_cpumask().
> In fact,
flight 59014 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59014/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 14 guest-localmigrate.2
fail REGR. vs. 58958
Ian Campbell writes ("Re: [Xen-devel] [CALL-FOR-AGENDA] Monthly Xen.org
Technical Call (2015-07-08)"):
> On Thu, 2015-07-02 at 09:45 +0100, Ian Campbell wrote:
> > Shall I put up a poll of some sort to gather preferred timeslot options
> > out of that set?
>
> Please can everyone who is intereste
Oh, I forgot the version number and change history.
This patchset should be version 2.
The change history should be:
1> Split the original patch into 2;
2> Take Paul Durrant’s comments:
a> Add a name member in the struct rb_rangeset, and use the ‘q’
debug key to dump the ranges in ioreq serve
> -Original Message-
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: 02 July 2015 16:12
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Andrew Cooper; Keir (Xen.org); Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v5 05/16] x86/hvm: unify internal portio and
> mmio int
El 02/07/15 a les 17.02, Paul Durrant ha escrit:
>> -Original Message-
>> From: Roger Pau Monné [mailto:roger@citrix.com]
>> Sent: 02 July 2015 15:52
>> To: Paul Durrant; xen-de...@lists.xenproject.org
>> Cc: Andrew Cooper; Keir (Xen.org); Jan Beulich
>> Subject: Re: [Xen-devel] [PATCH
> -Original Message-
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: 02 July 2015 15:52
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Andrew Cooper; Keir (Xen.org); Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v5 05/16] x86/hvm: unify internal portio and
> mmio int
Starts a second QEMU to provide PV backends in userspace to HVM guests.
Use both dcs->dmss.pvqemu and dcs->dmss.dm to keep track of the starting
QEMUs. Introduce two new fields to struct libxl__dm_spawn_state: dcs to
store the pointer to libxl__domain_create_state, and rc to store the
return code.
When QEMU restricts its xenstore connection, it cannot provide PV
backends. A separate QEMU instance is required to provide PV backends in
userspace, such as qdisk. With two separate instances, it is not
possible to take advantage of vkb for mouse and keyboard, as the QEMU
that emulates the graphic
Check whether QEMU supports the xsrestrict option, by parsing its --help
output. Store the result on xenstore for future reference on a per QEMU
binary basis, so that device_model_override still works fine with it.
Replace / with _ in the QEMU binary path before writing it to xenstore,
so that it
Change the qdisk-backend-pid path on xenstore from
libxl/$DOMID/qdisk-backend-pid to /local/domain/$DOMID/image/pvqemu-pid to be
more similar to the device-model path.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- update xenstore-paths.markdown
---
docs/misc/xenstore-paths.markdown |
Change the QEMU xenstore watch path to
/local/domain/$LIBXL_TOOLSTACK_DOMID/device-model/$DOMID/$EMULATOR_ID.
Currently two emulator_ids are statically allocated: one for device models and
one for pv qemus.
Add a parameter to libxl__device_model_xs_path to distinguish the device
model from the pv
The device model is going to restrict its xenstore connection to $DOMID
level, using XS_RESTRICT, only implemented by oxenstored at present.
Let qemu-xen access
/local/domain/$LIBXL_TOOLSTACK_DOMID/device-model/$DOMID, as it is
required by QEMU to read/write the physmap. It doesn't contain any
inf
Hi all,
this patch series changes libxl to start QEMU as device model with the
new xsrestrict option (http://marc.info/?l=xen-devel&m=143341692707358).
It also starts a second QEMU to provide PV backends in userspace (qdisk)
to HVM guests.
Changes in v4:
- update xenstore-paths.markdown
- add er
At 12:32 +0100 on 02 Jul (1435840328), George Dunlap wrote:
> On 07/02/2015 12:25 PM, Tim Deegan wrote:
> > At 12:09 +0100 on 02 Jul (1435838956), Andrew Cooper wrote:
> >> On 02/07/15 11:48, George Dunlap wrote:
> >>> Now in p2m_set_mem_access(), rather than just using an unsigned long in
> >>> th
At 13:43 +0100 on 02 Jul (1435844582), Ben Catterall wrote:
> Removed as they were wrappers around map_domain_page() to
> make it appear to take an mfn_t type.
>
> Signed-off-by: Ben Catterall
Reviewed-by: Tim Deegan
___
Xen-devel mailing list
Xen-de
AMD and Intel PMU register initialization and helpers that determine
whether a register belongs to PMU.
This and some of subsequent PMU emulation code is somewhat similar to
Xen's PMU implementation.
Signed-off-by: Boris Ostrovsky
Reviewed-by: David Vrabel
---
arch/x86/xen/pmu.c | 153
Map shared data structure that will hold CPU registers, VPMU context,
V/PCPU IDs of the CPU interrupted by PMU interrupt. Hypervisor fills
this information in its handler and passes it to the guest for further
processing.
Set up PMU VIRQ.
Now that perf infrastructure will assume that PMU is avail
Set Xen's PMU mode via /sys/hypervisor/pmu/pmu_mode. Add XENPMU hypercall.
Signed-off-by: Boris Ostrovsky
---
Documentation/ABI/testing/sysfs-hypervisor-pmu | 23 +
arch/x86/include/asm/xen/hypercall.h | 6 ++
drivers/xen/sys-hypervisor.c | 127
1 - 100 of 197 matches
Mail list logo
