On Mon, Jun 15, 2015 at 05:02:59PM +0100, Jan Beulich wrote:
> >>> On 03.06.15 at 06:53, wrote:
> > @@ -209,6 +215,23 @@ void psr_ctxt_switch_to(struct domain *d)
> > }
> > }
> >
> > +static int cat_cpu_prepare(unsigned int cpu)
> > +{
> > +struct psr_cat_socket_info *info;
> > +
> > +
>>> On 22.06.15 at 18:24, wrote:
> "Jan Beulich" writes:
>
> On 22.06.15 at 18:00, wrote:
>>> "Jan Beulich" writes:
>>>
>>> On 03.06.15 at 15:35, wrote:
> @@ -1129,8 +1129,9 @@ void unmap_vcpu_info(struct vcpu *v)
> mfn = v->vcpu_info_mfn;
> unmap_domain_page_gl
Hello,
El 22/06/15 a les 19.55, Stefano Stabellini ha escrit:
> Hi Roger,
>
> given that this patch series is actually using the Xen "hvm" builder, I
> take that all the PVH code paths in Xen or the guest kernel are not
> actually used, correct? This is more like PV on HVM without QEMU, right?
>
>>> On 22.06.15 at 19:02, wrote:
> OK, I didn't get the part of the question. AFAICT yes, FreeBSD will
> access the low 256 bytes of the config space. For example the stub to
> write to a cfg register is as follows:
>
> void
> pci_cfgregwrite(int bus, int slot, int func, int reg, u_int32_t data
On Tue, Jun 16, 2015 at 08:08:34AM +0100, Jan Beulich wrote:
> >>> On 03.06.15 at 06:53, wrote:
> > +int psr_set_l3_cbm(struct domain *d, unsigned int socket, uint64_t cbm)
> > +{
> > +unsigned int old_cos, cos;
> > +struct psr_cat_cbm *map, *found = NULL;
> > +struct psr_cat_socket_in
>>> On 22.06.15 at 21:31, wrote:
>> @@ -1804,8 +1804,12 @@ static bool_t pci_cfg_ok(struct domain *
>> start |= CF8_ADDR_HI(currd->arch.pci_cf8);
>> }
>>
>> -return !xsm_pci_config_permission(XSM_HOOK, currd, machine_bdf,
>> - start, sta
El 23/06/15 a les 9.20, Jan Beulich ha escrit:
On 22.06.15 at 19:02, wrote:
>> OK, I didn't get the part of the question. AFAICT yes, FreeBSD will
>> access the low 256 bytes of the config space. For example the stub to
>> write to a cfg register is as follows:
>>
>> void
>> pci_cfgregwrite
>>> On 23.06.15 at 05:40, wrote:
> On 18/06/2015 22:30, Jan Beulich wrote:
>> >>> On 11.06.15 at 10:27, wrote:
>> > Register the CPU hotplug notifier when the driver is registered, and
>> > move the driver register function to the cpufreq.c.
>>
>> The first half of the sentence fails to say why.
On 23/06/2015 15:31, Jan Beulich wrote:
> >>> On 23.06.15 at 05:40, wrote:
> > On 18/06/2015 22:30, Jan Beulich wrote:
> >> >>> On 11.06.15 at 10:27, wrote:
> >> > -static int __init cpufreq_presmp_init(void)
> >> > +int cpufreq_register_driver(struct cpufreq_driver *driver_data)
> >> > {
> >> >
>>> On 23.06.15 at 08:16, wrote:
> On 19/06/2015 17:44, Jan Beulich wrote:
>> >>> On 11.06.15 at 10:28, wrote:
>> > cpufreq_cpu_policy is used in intel_pstate_set_pstate(), so we change
>> > to NULL it after the call of cpufreq_driver->exit. Otherwise, a
>> > calltrace will show up on your screen
>>> On 23.06.15 at 10:01, wrote:
> On 23/06/2015 15:31, Jan Beulich wrote:
>> >>> On 23.06.15 at 05:40, wrote:
>> > On 18/06/2015 22:30, Jan Beulich wrote:
>> >> >>> On 11.06.15 at 10:27, wrote:
>> >> > -static int __init cpufreq_presmp_init(void)
>> >> > +int cpufreq_register_driver(struct cpuf
>>> On 23.06.15 at 09:29, wrote:
> FreeBSD never supported PV Dom0 operation, it only had a very minimal
> and crappy i386 PV DomU support which has now been completely removed.
> Maybe you are confusing it with NetBSD, which does have PV Dom0 support
> since a long time ago?
Very likely.
> Yes,
El 22/06/15 a les 20.05, Konrad Rzeszutek Wilk ha escrit:
> On Mon, Jun 22, 2015 at 06:55:12PM +0100, Stefano Stabellini wrote:
>> Hi Roger,
>>
>> given that this patch series is actually using the Xen "hvm" builder, I
>> take that all the PVH code paths in Xen or the guest kernel are not
>> actual
flight 58843 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58843/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 33866
build-amd64-rumpuserx
On 23/06/2015 16:08, Jan Beulich wrote:
> >>> On 23.06.15 at 08:16, wrote:
> > On 19/06/2015 17:44, Jan Beulich wrote:
> >> >>> On 11.06.15 at 10:28, wrote:
> >> > cpufreq_cpu_policy is used in intel_pstate_set_pstate(), so we
> >> > change to NULL it after the call of cpufreq_driver->exit.
> >>
>>> On 22.06.15 at 18:10, wrote:
> On 06/22/2015 11:10 AM, Jan Beulich wrote:
>>
>>> +switch ( op )
>>> +{
>>> +case XENPMU_mode_set:
>>> +{
>>> +if ( (pmu_params.val & ~(XENPMU_MODE_SELF | XENPMU_MODE_HV)) ||
>>> + (hweight64(pmu_params.val) > 1) )
>>> +
On 23/06/2015 16:11, Jan Beulich wrote:
> >>> On 23.06.15 at 10:01, wrote:
> > On 23/06/2015 15:31, Jan Beulich wrote:
> >> >>> On 23.06.15 at 05:40, wrote:
> >> > On 18/06/2015 22:30, Jan Beulich wrote:
> >> >> >>> On 11.06.15 at 10:27, wrote:
> >> >> > -static int __init cpufreq_presmp_init(vo
>>> On 23.06.15 at 09:08, wrote:
> On Mon, Jun 15, 2015 at 05:02:59PM +0100, Jan Beulich wrote:
>> >>> On 03.06.15 at 06:53, wrote:
>> > @@ -209,6 +215,23 @@ void psr_ctxt_switch_to(struct domain *d)
>> > }
>> > }
>> >
>> > +static int cat_cpu_prepare(unsigned int cpu)
>> > +{
>> > +s
>>> On 23.06.15 at 09:19, wrote:
> On Tue, Jun 16, 2015 at 08:08:34AM +0100, Jan Beulich wrote:
>> >>> On 03.06.15 at 06:53, wrote:
>> > +int psr_set_l3_cbm(struct domain *d, unsigned int socket, uint64_t cbm)
>> > +{
>> > +unsigned int old_cos, cos;
>> > +struct psr_cat_cbm *map, *found
>>> On 23.06.15 at 10:24, wrote:
> On 23/06/2015 16:11, Jan Beulich wrote:
>> >>> On 23.06.15 at 10:01, wrote:
>> > On 23/06/2015 15:31, Jan Beulich wrote:
>> >> >>> On 23.06.15 at 05:40, wrote:
>> >> > On 18/06/2015 22:30, Jan Beulich wrote:
>> >> >> >>> On 11.06.15 at 10:27, wrote:
>> >> >> >
Il 22/06/2015 17:32, Stefano Stabellini ha scritto:
On Mon, 22 Jun 2015, Fabio Fantoni wrote:
Usage:
ahci=0|1 (default=0)
If enabled adds ich9 disk controller in ahci mode and uses it with
upstream qemu to emulate disks instead of ide.
It doesn't support cdroms which still using ide (cdroms wil
On Mon, 2015-06-22 at 14:33 -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 17, 2015 at 03:35:02PM +0100, Stefano Stabellini wrote:
> > On Wed, 17 Jun 2015, Ian Campbell wrote:
> > > On Wed, 2015-06-17 at 07:14 -0700, Manish Jaggi wrote:
> > > >
> > > > On Wednesday 17 June 2015 06:43 AM, Ian Ca
On 23/06/2015 09:41, Wei Wang wrote:
> On 11/06/2015 16:31, Wei Wang wrote:
> > Add support in the pmstat.c so that the xenpm tool can request to
> > access the intel_pstate driver.
>
> I want to propose some other changes here to commonize the intel_pstate
> implementation in this common code (pm
>>> On 23.06.15 at 10:21, wrote:
> On 23/06/2015 16:08, Jan Beulich wrote:
>> >>> On 23.06.15 at 08:16, wrote:
>> > On 19/06/2015 17:44, Jan Beulich wrote:
>> >> >>> On 11.06.15 at 10:28, wrote:
>> >> > cpufreq_cpu_policy is used in intel_pstate_set_pstate(), so we
>> >> > change to NULL it afte
>>> On 23.06.15 at 03:40, wrote:
> Hi Jan,
> On 11/06/2015 16:31, Wei Wang wrote:
>> Add support in the pmstat.c so that the xenpm tool can request to access the
>> intel_pstate driver.
>
> I want to propose some other changes here to commonize the intel_pstate
> implementation in this common co
Without this then anything which uses cr-daily-branch produces the
rather cryptic:
+ test -f daily.xsettings
++ ./ap-print-url xen-unstable
with-lock-ex ./ap-print-url: /lock: Permission denied
+ treeurl=
FAILED rc=255
Which has caught out one or two people using standalone mo
flight 58831 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58831/
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 Tue, Jun 23, 2015 at 09:35:30AM +0100, Jan Beulich wrote:
> >>> On 23.06.15 at 09:19, wrote:
> > On Tue, Jun 16, 2015 at 08:08:34AM +0100, Jan Beulich wrote:
> >> >>> On 03.06.15 at 06:53, wrote:
> >> > +int psr_set_l3_cbm(struct domain *d, unsigned int socket, uint64_t cbm)
> >> > +{
> >> > +
>>> On 22.06.15 at 18:21, wrote:
> Since the NMI handler can now recognize watchdog NMIs, make
> check_nmi_watchdog() only check for at least one watchdog NMI. This
> prevents false negatives caused by other processors (which may be
> being power managed by the BIOS) running at reduced clock freq
On 22/06/15 20:18, Konrad Rzeszutek Wilk wrote:
> Thank you for posting this!
>
> Some comments below.
>
>> Design
>> ==
>>
>> `struct sysctl_physinfo.levelling_caps`
>> ---
>>
>> Xen shall gain a new physinfo field which reports the degree to which it can
>>
>>> On 23.06.15 at 11:03, wrote:
> On Tue, Jun 23, 2015 at 09:35:30AM +0100, Jan Beulich wrote:
>> >>> On 23.06.15 at 09:19, wrote:
>> > On Tue, Jun 16, 2015 at 08:08:34AM +0100, Jan Beulich wrote:
>> >> >>> On 03.06.15 at 06:53, wrote:
>> >> > +int psr_set_l3_cbm(struct domain *d, unsigned int
Usage:
ahci=0|1 (default=0)
If enabled adds ich9 disk controller in ahci mode and uses it with
upstream qemu to emulate disks instead of ide.
It doesn't support cdroms which still using ide (cdroms will use
"-device ide-cd" as new qemu parameter)
Ahci requires new qemu parameter but for now other
On Tue, 2015-06-23 at 02:18 +, osstest service user wrote:
> flight 58828 osstest real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/58828/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-armhf
On Tue, 2015-06-23 at 09:59 +0100, Ian Campbell wrote:
> Without this then anything which uses cr-daily-branch produces the
> rather cryptic:
>
> + test -f daily.xsettings
> ++ ./ap-print-url xen-unstable
> with-lock-ex ./ap-print-url: /lock: Permission denied
> + treeurl=
> FA
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, June 18, 2015 4:10 PM
> To: Wu, Feng
> Cc: andrew.coop...@citrix.com; george.dun...@eu.citrix.com; Tian, Kevin;
> Zhang, Yang Z; xen-devel@lists.xen.org; k...@xen.org
> Subject: RE: [RFC v2 14/15] Suppre
>>> On 22.06.15 at 18:11, wrote:
> Introduce a very simple (and dummy) domain loader to be used to load the
> firmware (hvmloader) into HVM guests. Since hmvloader is just a 32bit elf
> executable the loader is fairly simple.
But hvmloader gets loaded fine today - why is this needed?
Jan
_
>>> On 22.06.15 at 18:11, wrote:
> @@ -213,6 +214,9 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary *elf,
> elf, note, sizeof(*parms->f_supported), i);
> break;
>
> +case XEN_ELFNOTE_PHYS_ENTRY:
> +parms->phys_entry = val;
I don't think I've seen th
On 23/06/15 10:09, Jan Beulich wrote:
On 22.06.15 at 18:21, wrote:
>> Since the NMI handler can now recognize watchdog NMIs, make
>> check_nmi_watchdog() only check for at least one watchdog NMI. This
>> prevents false negatives caused by other processors (which may be
>> being power managed
El 23/06/15 a les 11.29, Jan Beulich ha escrit:
On 22.06.15 at 18:11, wrote:
>> Introduce a very simple (and dummy) domain loader to be used to load the
>> firmware (hvmloader) into HVM guests. Since hmvloader is just a 32bit elf
>> executable the loader is fairly simple.
>
> But hvmloader g
On 22 June 2015 at 14:08, Stefano Stabellini
wrote:
> The following changes since commit 00967f4e0bab246679d0ddc32fd31a7179345baf:
>
> Merge remote-tracking branch 'remotes/agraf/tags/signed-s390-for-upstream'
> into staging (2015-06-05 12:04:42 +0100)
>
> are available in the git repository at
El 23/06/15 a les 11.35, Jan Beulich ha escrit:
On 22.06.15 at 18:11, wrote:
>> @@ -213,6 +214,9 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary
>> *elf,
>> elf, note, sizeof(*parms->f_supported), i);
>> break;
>>
>> +case XEN_ELFNOTE_PHYS_ENTRY:
>> +
>>> On 22.06.15 at 18:11, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -343,7 +343,7 @@ u64 hvm_get_guest_tsc_adjust(struct vcpu *v)
> void hvm_migrate_timers(struct vcpu *v)
> {
> /* PVH doesn't use rtc and emulated timers, it uses pvclock mechanism. */
> -
Ian Campbell writes ("[PATCH OSSTEST] Add some sanity checks for presence of
Repos configuration"):
> Without this then anything which uses cr-daily-branch produces the
> rather cryptic:
>
> + test -f daily.xsettings
> ++ ./ap-print-url xen-unstable
> with-lock-ex ./ap-print-url: /loc
>>> On 22.06.15 at 18:11, wrote:
> Enable this hypercall for 64bit HVM guests in order to fetch the e820 memory
> map in the absence of an emulated BIOS. The memory map is populated and
> notified to Xen in arch_setup_meminit_hvm.
I see no reason why this should be limited to 64-bit guests.
Jan
On 23/06/15 00:02, Chris (Christopher) Brand wrote:
> I’ve been trying to figure out why Xen only reports 2GB on my ARM
> platform that actually has 3GB, and I think I’ve found a bug, but I’m
> not familiar enough with the Xen code to fix it.
>
> The relevant parts of my dts are:
>
> /dts-v1/;
>
On 2015/6/19 10:02, Chen, Tiejun wrote:
On 2015/6/18 16:05, Jan Beulich wrote:
On 18.06.15 at 09:01, wrote:
On 2015/6/18 14:29, Jan Beulich wrote:
On 18.06.15 at 08:17, wrote:
On 2015/6/17 17:24, Jan Beulich wrote:
On 17.06.15 at 11:18, wrote:
On 2015/6/17 17:02, Jan Beulich wrote:
On 1
All,
I am pleased to announce the release of Xen 4.5.1. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.5
(tag RELEASE-4.5.1) or from the XenProject download page
http://www.xenproject.org/downloads/xen-archives/xen-4
>>> On 23.06.15 at 11:34, wrote:
> On 23/06/15 10:09, Jan Beulich wrote:
> On 22.06.15 at 18:21, wrote:
>>> Since the NMI handler can now recognize watchdog NMIs, make
>>> check_nmi_watchdog() only check for at least one watchdog NMI. This
>>> prevents false negatives caused by other process
By providing an explicit fetch method in cri-getconfig which checks
things.
Without this then anything which uses cr-daily-branch produces the
rather cryptic:
+ test -f daily.xsettings
++ ./ap-print-url xen-unstable
with-lock-ex ./ap-print-url: /lock: Permission denied
+ treeurl=
By providing an explicit fetch method in cri-getconfig which checks
things.
Without this then anything which uses cr-daily-branch produces the
rather cryptic:
+ test -f daily.xsettings
++ ./ap-print-url xen-unstable
with-lock-ex ./ap-print-url: /lock: Permission denied
+ treeurl=
On Tue, 2015-06-23 at 10:54 +0100, Ian Campbell wrote:
> By providing an explicit fetch method in cri-getconfig which checks
> things.
>
> Without this then anything which uses cr-daily-branch produces the
> rather cryptic:
>
> + test -f daily.xsettings
> ++ ./ap-print-url xen-unstable
>
>>> On 23.06.15 at 11:45, wrote:
> We seem to have gone off list -- not on purpose I think?
No, sorry - when I trimmed the Cc list I trimmed it a little too much.
Re-added.
Jan
> On Tue, 2015-06-23 at 10:20 +0100, Jan Beulich wrote:
>> >>> On 23.06.15 at 11:16, wrote:
>> > On Mon, Jun 22, 2015
On Tue, 2015-06-23 at 10:44 +0100, David Vrabel wrote:
> On 23/06/15 00:02, Chris (Christopher) Brand wrote:
> > I’ve been trying to figure out why Xen only reports 2GB on my ARM
> > platform that actually has 3GB, and I think I’ve found a bug, but I’m
> > not familiar enough with the Xen code to f
On Tue, 2015-06-23 at 10:54 +0100, Ian Campbell wrote:
Sorry for this, I hit "v, CR, 2" instead of "v, 2, CR" and apparently
didn't get to Ctrl-C quick enough.
This is the same as v2 which followed shortly after.
Ian.
___
Xen-devel mailing list
Xen-d
RMRR reserved regions must be setup in the pfn space with an identity
mapping to reported mfn. However existing code has problem to setup
correct mapping when VT-d shares EPT page table, so lead to problem
when assigning devices (e.g GPU) with RMRR reported. So instead, this
patch aims to setup ide
v4:
* Change one condition inside patch #2, "xen/x86/p2m: introduce
set_identity_p2m_entry",
if ( p2mt == p2m_invalid || p2mt == p2m_mmio_dm )
to make sure we just catch our requirement.
* Inside patch #3, "xen/vtd: create RMRR mapping",
Instead of intel_iommu_unmap_page(), we should use
>>> On 23.06.15 at 11:40, wrote:
> El 23/06/15 a les 11.35, Jan Beulich ha escrit:
> On 22.06.15 at 18:11, wrote:
>>> @@ -213,6 +214,9 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary
> *elf,
>>> elf, note, sizeof(*parms->f_supported), i);
>>> break;
>>>
>>
From: Jan Beulich
This is a prerequisite for punching holes into HVM and PVH guests' P2M
to allow passing through devices that are associated with (on VT-d)
RMRRs.
CC: Jan Beulich
CC: Yang Zhang
CC: Kevin Tian
Signed-off-by: Jan Beulich
Signed-off-by: Tiejun Chen
Acked-by: Kevin Tian
---
v
When allocating mmio address for PCI bars, we need to make
sure they don't overlap with reserved regions.
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
CC: Ian Jackson
CC: Stefano Stabellini
CC: Ian Campbell
CC: Wei Liu
Signed-off-by: Tiejun Chen
---
v4:
* We have to re-design this as
We will introduce the hypercall xc_reserved_device_memory_map
approach to libxc. This helps us get rdm entry info according to
different parameters. If flag == PCI_DEV_RDM_ALL, all entries
should be exposed. Or we just expose that rdm entry specific to
a SBDF.
CC: Ian Jackson
CC: Stefano Stabelli
This patch parses to enable user configurable parameters to specify
RDM resource and according policies,
Global RDM parameter:
rdm = "type=none/host,reserve=strict/relaxed"
Per-device RDM parameter:
pci = [ 'sbdf, rdm_reserve=strict/relaxed' ]
Default per-device RDM policy is 'strict', wh
Now we can use that memory map to build our final
e820 table but it may need to reorder all e820
entries.
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
CC: Ian Jackson
CC: Stefano Stabellini
CC: Ian Campbell
CC: Wei Liu
Signed-off-by: Tiejun Chen
---
v4:
* Rename local variable, low_m
This patch introduces user configurable parameters to specify RDM
resource and according policies,
Global RDM parameter:
rdm = "type=none/host,reserve=strict/relaxed"
Per-device RDM parameter:
pci = [ 'sbdf, rdm_reserve=strict/relaxed' ]
Global RDM parameter, "type", allows user to specif
Here we'll construct a basic guest e820 table via
XENMEM_set_memory_map. This table includes lowmem, highmem
and RDMs if they exist. And hvmloader would need this info
later.
CC: Ian Jackson
CC: Stefano Stabellini
CC: Ian Campbell
CC: Wei Liu
Signed-off-by: Tiejun Chen
---
v4:
* Use goto sty
Currently we're intending to cover this kind of devices
with shared RMRR simply since the case of shared RMRR is
a rare case according to our previous experiences. But
late we can group these devices which shared rmrr, and
then allow all devices within a group to be assigned to
same domain.
CC: Ya
This patch enables XENMEM_memory_map in hvm. So hvmloader can
use it to setup the e820 mappings.
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
Signed-off-by: Tiejun Chen
Reviewed-by: Tim Deegan
Reviewed-by: Kevin Tian
Acked-by: Jan Beulich
---
v4:
* Just refine the patch head descripti
After commit 5dff8e9eedc7, "libxc/libxl: fill xc_hvm_build_args in
libxl" is introduced, we won't check to set args.mmio_size inside
xc_hvm_build as before. So instead, we need to do this before call
that.
CC: Ian Jackson
CC: Stefano Stabellini
CC: Ian Campbell
CC: Wei Liu
Signed-off-by: Tieju
We will create this sort of identity mapping as follows:
If the gfn space is unoccupied, we just set the mapping. If space
is already occupied by desired identity mapping, do nothing.
Otherwise, failure is returned.
And we also add a returning value to guest_physmap_remove_page()
then make that a
USB RMRR may conflict with guest BIOS region. In such case, identity
mapping setup is simply skipped in previous implementation. Now we
can handle this scenario cleanly with new policy mechanism so previous
hack code can be removed now.
CC: Yang Zhang
CC: Kevin Tian
Signed-off-by: Tiejun Chen
A
While building a VM, HVM domain builder provides struct hvm_info_table{}
to help hvmloader. Currently it includes two fields to construct guest
e820 table by hvmloader, low_mem_pgend and high_mem_pgend. So we should
check them to fix any conflict with RAM.
RMRR can reside in address space beyond 4
Previously we always fix that predefined boundary as 2G to handle
conflict between memory and rdm, but now this predefined boundar
can be changes with the parameter "rdm_mem_boundary" in .cfg file.
CC: Ian Jackson
CC: Stefano Stabellini
CC: Ian Campbell
CC: Wei Liu
Signed-off-by: Tiejun Chen
This patch passes rdm reservation policy to xc_assign_device() so the policy
is checked when assigning devices to a VM.
Note this also bring some fallout to python usage of xc_assign_device().
CC: Ian Jackson
CC: Stefano Stabellini
CC: Ian Campbell
CC: Wei Liu
CC: David Scott
Signed-off-by:
Now we get this map layout by call XENMEM_memory_map then
save them into one global variable memory_map[]. It should
include lowmem range, rdm range and highmem range. Note
rdm range and highmem range may not exist in some cases.
And here we need to check if any reserved memory conflicts with
[RES
This patch extends the existing hypercall to support rdm reservation policy.
We return error or just throw out a warning message depending on whether
the policy is "strict" or "relaxed" when reserving RDM regions in pfn space.
Note in some special cases, e.g. add a device to hwdomain, and remove a
This patch passes our rdm reservation policy inside libxl
when we assign a device or attach a device.
CC: Ian Jackson
CC: Stefano Stabellini
CC: Ian Campbell
CC: Wei Liu
Signed-off-by: Tiejun Chen
---
v4:
* Fix one typo, s/unkwon/unknown
* In command description, we should use "[]" to indica
>>> On 23.06.15 at 11:26, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Thursday, June 18, 2015 4:10 PM
>> >>> On 18.06.15 at 10:01, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Thursday, June 18, 2015 3:51 PM
>> >> >>> On 18.06.15 at 09:34, wrote:
>> >
On Tue, 23 Jun 2015, Jan Beulich wrote:
> All,
>
> I am pleased to announce the release of Xen 4.5.1. This is
> available immediately from its git repository
> http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.5
> (tag RELEASE-4.5.1) or from the XenProject download page
>
>>> On 23.06.15 at 11:57, wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1839,7 +1839,7 @@ static int rmrr_identity_mapping(struct domain *d,
> bool_t map,
>
> while ( base_pfn < end_pfn )
> {
> -if
Hi,
On 23/06/2015 10:44, David Vrabel wrote:
On 23/06/15 00:02, Chris (Christopher) Brand wrote:
I’ve been trying to figure out why Xen only reports 2GB on my ARM
platform that actually has 3GB, and I think I’ve found a bug, but I’m
not familiar enough with the Xen code to fix it.
The relevant
On Tue, 2015-06-23 at 11:08 +0100, Ian Campbell wrote:
> On Tue, 2015-06-23 at 10:57 +0100, Ian Campbell wrote:
> > On Tue, 2015-06-23 at 10:44 +0100, David Vrabel wrote:
> > > On 23/06/15 00:02, Chris (Christopher) Brand wrote:
> > > > I’ve been trying to figure out why Xen only reports 2GB on my
Hi,
On 23/06/2015 00:02, Chris (Christopher) Brand wrote:
I’ve been trying to figure out why Xen only reports 2GB on my ARM
platform that actually has 3GB, and I think I’ve found a bug, but I’m
not familiar enough with the Xen code to fix it.
/dts-v1/;
/ {
model = "Broadcom STB (7445d0)"
On Tue, 2015-06-23 at 10:57 +0100, Ian Campbell wrote:
> On Tue, 2015-06-23 at 10:44 +0100, David Vrabel wrote:
> > On 23/06/15 00:02, Chris (Christopher) Brand wrote:
> > > I’ve been trying to figure out why Xen only reports 2GB on my ARM
> > > platform that actually has 3GB, and I think I’ve foun
On Tue, 2015-06-23 at 10:16 +0100, Ian Campbell wrote:
> On Tue, 2015-06-23 at 02:18 +, osstest service user wrote:
> > flight 58828 osstest real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/58828/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
>
>>> On 6/16/2015 at 01:47 AM, in message <557f0fa7.2060...@eu.citrix.com>,
>>> George
Dunlap wrote:
> On 06/10/2015 04:20 AM, Chunyan Liu wrote:
> > Add pvusb APIs, including:
> > - attach/detach (create/destroy) virtual usb controller.
> > - attach/detach usb device
> > - list usb cont
Hi Vijay,
On 22/06/2015 13:01, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K
Helper functions to mange its devices using RB-tree
s/mange/manage/
are introduced in physical ITS driver.
This is global list of all the devices.
Signed-off-by: Vijaya Kumar K
---
xen/arch/arm/gic-v3-it
From: Imre Palik
Date: Fri, 19 Jun 2015 14:21:51 +0200
> From: "Palik, Imre"
>
> Commit edafc132baac ("xen-netback: making the bandwidth limiter runtime
> settable")
> introduced the capability to change the bandwidth rate limit at runtime.
> But it also introduced a possible crashing bug.
>
M A Young writes ("Re: [Xen-devel] Xen 4.5.1 released"):
> On Tue, 23 Jun 2015, Jan Beulich wrote:
> > I am pleased to announce the release of Xen 4.5.1. This is
> > available immediately from its git repository
> > http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.5
> > (t
On Tue, 2015-06-23 at 11:08 +0100, Julien Grall wrote:
> > reg = <0x0 0x0 0x0 0x4000 0x0 0x4000 0x0 0x4000>;
>
> Although, what the rest of the node used for? Do we expect to parse it?
> I wasn't able to find a suitable bindings in the docs...
A reg can encode multiple r
On Tue, 23 Jun 2015, Peter Maydell wrote:
> On 22 June 2015 at 14:08, Stefano Stabellini
> wrote:
> > The following changes since commit 00967f4e0bab246679d0ddc32fd31a7179345baf:
> >
> > Merge remote-tracking branch
> > 'remotes/agraf/tags/signed-s390-for-upstream' into staging (2015-06-05
> >
On 23/06/2015 11:27, Ian Campbell wrote:
On Tue, 2015-06-23 at 11:08 +0100, Julien Grall wrote:
reg = <0x0 0x0 0x0 0x4000 0x0 0x4000 0x0 0x4000>;
Although, what the rest of the node used for? Do we expect to parse it?
I wasn't able to find a suitable bindings in the
...in hvmemul_read/write()
Add hvmemul_phys_mmio_access() and hvmemul_linear_mmio_access() functions
to reduce code duplication.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/emulate.c | 232
1
The implementation of mmio and portio intercepts is unnecessarily different.
This leads to much code duplication. This patch unifies much of the
intercept handling, leaving only distinct handlers for stdvga mmio and dpci
portio. Subsequent patches will unify those handlers.
Signed-off-by: Paul Dur
The struct just contains three methods and no data, so the name
hvm_mmio_ops more accurately reflects its content. A subsequent patch
introduces a new structure which more accurately warrants the name
hvm_mmio_handler so doing the rename in this purely cosmetic patch avoids
conflating functional an
...otherwise they will simply carry on to the next page using a normal
linear-to-phys translation.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/emulate.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/xen/arch
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/hpet.c |7 ---
xen/arch/x86/hvm/intercept.c
The is_mmio parameter can be inferred from the ioreq type.
Signed-off-by: Paul Durrant
Cc: Keir Fraser
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/emulate.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/e
Currently hvmemul_do_io() handles paging for I/O to/from a guest address
inline. This causes every exit point to have to execute:
if ( ram_page )
put_page(ram_page);
This patch introduces wrapper hvmemul_do_io_addr() and
hvmemul_do_io_buffer() functions. The latter is used for I/O to/from a X
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
---
xen/arch/x86/hvm/hvm.c |2 +
xen/ar
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 down into 18 patches (which are also available in
m
The check is done at the wrong point (since it is irrelevant if the
I/O is to be handled by the hypervisor) and its functionality can be
covered by returning X86EMUL_UNHANDLEABLE from hvm_send_assist_req()
instead.
This patch also removes the domain_crash() call from
hvm_send_assist_req(). Returni
1 - 100 of 277 matches
Mail list logo
