On 08/11/2017 13:24, Juergen Gross wrote:
>> My understanding of Xen is very rusty at this point, but I think a
>> "completely" legacy-free HVM domain will still have a PCI bus and the
>> Xen platform device on that bus.
>>
>> A PVH domain just knows how to access the Xen PV features.
>
> A HVM dom
On 08/11/2017 12:55, Juergen Gross wrote:
> On 08/11/17 12:18, Jan Beulich wrote:
> On 08.11.17 at 10:07, wrote:
>>> In case we are booted via the default boot entry by a generic loader
>>> like grub or OVMF it is necessary to distinguish between a HVM guest
>>> with a device model supporting
On 08/11/2017 10:07, Juergen Gross wrote:
> Add a new guest_late_init hook to the hypervisor_x86 structure. It
> will replace the current kvm_guest_init() call which is changed to
> make use of the new hook.
>
> Signed-off-by: Juergen Gross
The trivial KVM changes are of course
far is kvm. This commit adds a
> setter function for the pvti page and moves pvclock_pvti_cpu0_va
> to pvclock, which is a more generic place to have it; and would
> allow other PV clocksources to use it, such as Xen.
>
> Signed-off-by: Joao Martins
> Acked-by: Andy Lutomirski
...@lists.xenproject.org
Signed-off-by: Paolo Bonzini
---
Xen parts only compile-tested.
docs/qdev-device-use.txt | 12 +-
hw/i386/Makefile.objs |1 -
hw/i386/kvm/Makefile.objs |2 +-
hw/i386/kvm/pci-assign.c
delta = pvclock_clocksource_read(vcpu_time);/* time since system
> boot */
> - delta += now.tv_sec * (u64)NSEC_PER_SEC + now.tv_nsec;
> + delta += now.tv_sec * NSEC_PER_SEC + now.tv_nsec;
>
> now.tv_nsec = do_div(delta, NSEC_PER_SEC);
> now.tv
On 18/10/2017 10:32, Roger Pau Monné wrote:
>> I'll have a try to check how much the differences would affect. If it
>> would not take too much work, I'd like to adapt Xen NVDIMM enabling
>> patches to the all QEMU built ACPI. Otherwise, I'll fall back to Paolo
>> and MST's suggestions.
> I don't a
On 14/10/2017 00:46, Stefano Stabellini wrote:
> On Fri, 13 Oct 2017, Jan Beulich wrote:
> On 13.10.17 at 13:13, wrote:
>>> To Jan, Andrew, Stefano and Anthony,
>>>
>>> what do you think about allowing QEMU to build the entire guest ACPI
>>> and letting SeaBIOS to load it? ACPI builder code in
On 16/10/2017 14:16, Arnd Bergmann wrote:
> On Mon, Oct 16, 2017 at 2:08 PM, Paolo Bonzini wrote:
>> On 16/10/2017 10:11, Arnd Bergmann wrote:
>>> Thanks!
>>>
>>> Since you've looked at it overall, do you have an opinion on the question
>>
On 16/10/2017 10:11, Arnd Bergmann wrote:
> Thanks!
>
> Since you've looked at it overall, do you have an opinion on the question
> how to fix the PV interface to deal with the pvclock_wall_clock overflow?
It has to be done separately for each hypervisor.
In KVM, for example, it is probably best
On 12/10/2017 14:45, Haozhong Zhang wrote:
> Basically, QEMU builds two ROMs for guest, /rom@etc/acpi/tables and
> /rom@etc/table-loader. The former is unstructured to guest, and
> contains all data of guest ACPI. The latter is a BIOSLinkerLoader
> organized as a set of commands, which direct the g
On 02/10/2017 12:36, George Dunlap wrote:
>>> Although I'm not business man, I don't think the top cloud provider[s]
>>> would allow nested virtualization, however mature nested virtualization
>>> is. Even xen-pv is unable to be nested in the aws and azure.
>>
>> Check the contributors to KVM neste
- Lai Jiangshan ha scritto:
> On Sat, Sep 30, 2017 at 12:39 AM, Paolo Bonzini wrote:
> > On 29/09/2017 17:47, Lai Jiangshan wrote:
> >> Hello, all
> >>
> >> An interesting (at least to me) thinking came up to me when I found
> >> that th
On 29/09/2017 17:47, Lai Jiangshan wrote:
> Hello, all
>
> An interesting (at least to me) thinking came up to me when I found
> that the lguest was removed. But I don't have enough knowledge
> to find out the answer nor energy to implement it in some time.
>
> Is it possible to implement kvm-pv
that there's already a text notice at the
>> top of the header file, hence this commit simply enforces it more
>> explicitly and have both peers noticed when such changes happen.
>>
>> Signed-off-by: Joao Martins
>> Acked-by: Juergen Gross
>
>
On 18/08/2017 18:38, Eduardo Habkost wrote:
>>> I think you still need to do a check for vIOMMU being enabled.
>>
>> Yes, this will be done in the Xen tool stack and Qemu doesn't have such
>> knowledge. Operations of create, destroy Xen vIOMMU will be done in the
>> Xen tool stack.
>
> Shouldn't we
On 16/08/2017 02:22, Lan Tianyu wrote:
> Xen vIOMMU device model will be in Xen hypervisor. Skip vIOMMU
> check for Xen here when vcpu number is more than 255.
I think you still need to do a check for vIOMMU being enabled.
Paolo
> Signed-off-by: Lan Tianyu
> ---
> hw/i386/pc.c | 2 +-
> 1 file
On 09/08/2017 22:51, Lan Tianyu wrote:
> This patchset is to deal with MSI interrupt remapping request when guest
> updates MSI registers.
>
> Chao Gao (3):
> i386/msi: Correct mask of destination ID in MSI address
> xen-pt: bind/unbind interrupt remapping format MSI
> msi: Handle remappable
> > Thanks---however, after re-reading xen-mapcache.c, dma needs to be false
> > for unlocked mappings.
>
> If there is a DMA operation already in progress, it means that we'll
> already have a locked mapping for it.
Yes, I only wanted to say that qemu_ram_ptr_length should pass dma=false
when c
- Original Message -
> From: "Stefano Stabellini"
> To: "Paolo Bonzini"
> Cc: "Anthony PERARD" , "Stefano Stabellini"
> ,
> xen-devel@lists.xen.org, qemu-de...@nongnu.org
> Sent: Tuesday, July 25, 2017 8:08:21 PM
> Subject:
> Hi,
>
> Commits 04bf2526ce (exec: use qemu_ram_ptr_length to access guest ram)
> start using qemu_ram_ptr_length() instead of qemu_map_ram_ptr().
> That result in calling xen_map_cache() with lock=true, but this mapping
> is never invalidated.
> So QEMU use more and more RAM until it stop workin
On 20/06/2017 15:47, Paul Durrant wrote:
> This patch allocates an IOThread object for each xen_disk instance and
> sets the AIO context appropriately on connect. This allows processing
> of I/O to proceed in parallel.
>
> The patch also adds tracepoints into xen_disk to make it possible to
> foll
On 09/05/2017 21:04, Stefano Stabellini wrote:
> Assert that the return value is not an error. This issue was found by
> Coverity.
>
> CID: 1374831
>
> Signed-off-by: Stefano Stabellini
> CC: gr...@kaod.org
> CC: pbonz...@redhat.com
> CC: Eric Blake
Queued, thanks.
Paolo
> ---
> util/osli
assumed to be [a], while
> mappings created by address_space_map->qemu_ram_ptr_length are assumed
> to be [b].
>
> The goal of the patch is to make debugging and system understanding
> easier.
Sure, why not.
Acked-by: Paolo Bonzini
Paolo
> Signed-off-by: Stefa
again,
Eric, are you using the scripts/cocci-macro-file.h?
commit 6ad978e9f40d3edfd9f4a86b4a60e3523eff08fe
Author: Paolo Bonzini
Date: Wed May 18 11:11:55 2016 +0200
coccinelle: add g_assert_cmp* to macro file
This helps applying semantic patches to unit tests.
On 29/03/2017 01:54, Stefano Stabellini wrote:
>>> I understand your point of view, and honestly it wouldn't be a problem
>>> doing it the way you suggested either. However, I think that going
>>> forward it will be less of a maintenance pain to keep ring.h in sync,
>>> compared to maintaining a
On 20/03/2017 15:17, Roger Pau Monné wrote:
>>> Hi Paolo:
>>> Thanks for review. For Xen side, we won't reuse Intel IOMMU device model
>>> in Qemu and create counterpart in Xen hypervisor. The reasons are
>>> 1) Avoid round trips between Qemu and Xen hypervisor
>>> 2) Ease of integration with t
On 20/03/2017 03:40, Lan Tianyu wrote:
>>> Xen only supports emulated I440 and so we enable vIOMMU with emulated
>>> I440 chipset. This works on Linux and Windows guest.
>> Any plans to change this? Why is Xen not able to use Q35 with Intel
>> IOMMU, with only special hooks for interrupt remappi
On 17/03/2017 12:29, Lan Tianyu wrote:
> This patchset is to add Xen vIOMMU device model and handle
> irq remapping stuffs. Xen vIOMMU emulation is in the Xen hypervisor
> and the new device module in Qemu works as hypercall wrappers to
> create and destroy vIOMMU in hypervisor.
>
> Xen only sup
On 16/03/2017 21:01, Stefano Stabellini wrote:
> Change Makefile.objs to use CONFIG_XEN instead of CONFIG_XEN_BACKEND, so
> that the Xen backends are only built for targets that support Xen.
>
> Set CONFIG_XEN in the toplevel Makefile to ensure that files that are
> built only once pick up Xen s
On 14/03/2017 21:23, Stefano Stabellini wrote:
> On Tue, 14 Mar 2017, Stefano Stabellini wrote:
>>> Then you add to Makefile:
>>>
>>> CONFIG_SOFTMMU := $(if $(filter %-softmmu,$(TARGET_DIRS)),y)
>>> CONFIG_USER_ONLY := $(if $(filter %-user,$(TARGET_DIRS)),y)
>>> +CONFIG_XEN := $(CONFIG_XEN_BACK
On 14/03/2017 00:55, Stefano Stabellini wrote:
> CONFIG_XEN_BACKEND is currently set when the host supports Xen,
> regardless of the chosen targets. As a consequence, Xen backends can be
> enabled even on targets that don't support Xen.
>
> Fix the issue by setting CONFIG_XEN_BACKEND only for ta
On 20/02/2017 20:54, Peter Zijlstra wrote:
> On Mon, Feb 20, 2017 at 01:36:02PM -0500, Waiman Long wrote:
>> Waiman Long (2):
>> x86/paravirt: Change vcp_is_preempted() arg type to long
>> x86/kvm: Provide optimized version of vcpu_is_preempted() for x86-64
>>
>> arch/x86/include/asm/paravir
> Paolo, how stable, non-rebasing are the KVM tree commits?
Whatever ends in linux-next is stable. I have a separate rebasing branch,
but it's not part of linux-next by design.
> Or should we keep Andy's KVM patches together with the GDT patches? Either
> workflow works for me - it's your call
init functions due to us
> * using paravirt patching and jump labels patching and having to do
> @@ -138,7 +136,7 @@ void __init xen_init_spinlocks(void)
> pv_lock_ops.queued_spin_unlock =
> PV_CALLEE_SAVE(__pv_queued_spin_unlock);
> pv_lock_ops.wait = xen_qlock_wait;
> pv_lock_ops.kick = xen_qlock_kick;
> - pv_lock_ops.vcpu_is_preempted = PV_CALLEE_SAVE(xen_vcpu_stolen);
> + pv_lock_ops.vcpu_is_preempted = xen_vcpu_stolen;
> }
>
> static __init int xen_parse_nopvspin(char *arg)
>
Acked-by: Paolo Bonzini
Thank you very much!
Paolo
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 21/12/2016 15:15, Eduardo Habkost wrote:
>>
>> ifeq ($(CONFIG_SOFTMMU),y)
>> obj-$(CONFIG_KVM) += kvm-all.c
>> obj-$(call lnot, $(CONFIG_KVM)) += kvm-stub.c
>> endif
>>
>> similar to what is done already in Makefile.objs?
> I assume you mean:
>
> ifeq ($(CONFIG_SOFTMMU),y)
> obj-$(CONFIG_KV
On 21/12/2016 14:14, Eduardo Habkost wrote:
> On Wed, Dec 21, 2016 at 12:21:44PM +0100, Paolo Bonzini wrote:
>>
>>
>> On 20/12/2016 18:43, Eduardo Habkost wrote:
>>> This moves the KVM and Xen files to the an accel/ subdir.
>>>
>>> Instead of movin
c.
>
> Maybe a sysemu/ subdir? In that case, should we still create an
> accel/ subdir, or move xen-*, kvm-* and friends to sysemu/ too?
>
> Cc: Paolo Bonzini
> Cc: k...@vger.kernel.org
> Cc: Christoffer Dall
> Cc: Anthony Perard
> Cc: Stefano Stabellini
> Cc: xe
On 28/10/2016 10:11, Pan Xinhui wrote:
> change from v5:
> spilt x86/kvm patch into guest/host part.
> introduce kvm_write_guest_offset_cached.
> fix some typos.
> rebase patch onto 4.9.2
Acked-by: Paolo Bonzini
Thanks,
Paolo
> change from v4:
>
> So we are better leave it as is. Maybe we need to rename some functions in
> that file.
> __iirc__ adding xen_frontend.c is one of Stefano's comments in previous v6
> or v7..
I agree; it's quite possible that code can be shared between backend and
frontend (renaming functions as needed), and
On 09/10/2016 21:50, Emil Condrea wrote:
> On Tue, Oct 4, 2016 at 11:06 AM, Paolo Bonzini wrote:
>>
>>
>> On 04/10/2016 08:43, Emil Condrea wrote:
>>> xen_be_frontend_changed -> xen_fe_frontend_changed
>>
>> This is not correct. The front-end is
On 04/10/2016 10:06, Paolo Bonzini wrote:
>
>
> On 04/10/2016 08:43, Emil Condrea wrote:
>> xen_be_frontend_changed -> xen_fe_frontend_changed
>
> This is not correct. The front-end is implemented in the guest domain,
> while the back-end is implemented in the
On 04/10/2016 08:43, Emil Condrea wrote:
> xen_be_frontend_changed -> xen_fe_frontend_changed
This is not correct. The front-end is implemented in the guest domain,
while the back-end is implemented in the dom0 or stubdom.
This function processes *in the backed* a notification that the fronten
On 01/09/2016 14:11, Olaf Hering wrote:
> Update unplug in Xen HVM guests to cover more cases.
> Please review.
>
> Olaf
>
> Olaf Hering (2):
> xen_platform: unplug also SCSI disks
> xen_platform: SUSE xenlinux unplug for emulated PCI
>
> hw/i386/xen/xen_platform.c | 36 ++
On 15/07/2016 12:41, Juergen Gross wrote:
> On 15/07/16 12:35, Paolo Bonzini wrote:
>>
>>
>> On 15/07/2016 12:12, Gerd Hoffmann wrote:
>>> On Fr, 2016-07-15 at 12:02 +0200, Paolo Bonzini wrote:
>>>>
>>>> On 15/07/2016 10:47, Juergen Gro
On 15/07/2016 12:12, Gerd Hoffmann wrote:
> On Fr, 2016-07-15 at 12:02 +0200, Paolo Bonzini wrote:
>>
>> On 15/07/2016 10:47, Juergen Gross wrote:
>>> Nothing scaring and no real difference between working and not working
>>> variant.
>>>
>>>
On 15/07/2016 12:07, Peter Lieven wrote:
> Am 15.07.2016 um 12:02 schrieb Paolo Bonzini:
>>
>> On 15/07/2016 10:47, Juergen Gross wrote:
>>> Nothing scaring and no real difference between working and not working
>>> variant.
>>>
>>> Meanwhile
On 15/07/2016 10:47, Juergen Gross wrote:
> Nothing scaring and no real difference between working and not working
> variant.
>
> Meanwhile I've been digging a little bit deeper and found the reason:
> libxenstore is setting up a reader thread which is waiting for the
> watch to fire. With above
r);
> if (block) {
> -*offset = (host - block->host);
> +*offset = ram_addr - block->offset;
> }
> rcu_read_unlock();
> return block;
>
Acked-by: Paolo Bonzini
Feel free to send a pull req
- Original Message -
> From: "Anthony PERARD"
> To: "Paul Durrant"
> Cc: qemu-de...@nongnu.org, xen-de...@lists.xenproject.org, "Stefano
> Stabellini" , "Paolo
> Bonzini"
> Sent: Wednesday, May 25, 2016 5:52:32 PM
> Su
On 18/05/2016 21:34, Peter Zijlstra wrote:
>> I don't know of any enterprise distro that is shipping anything
>> > more modern than 4.1?
> RHEL 7-- v3.10
> SLES 12 -- v3.12
> Debian Jessie -- v3.16
> Ubuntu 16.04 LTS -- v4.4
>
> But wait
n_io_add/del so that sections with
> memory-region ops pointing at 'unassigned_io_ops' are ignored.
>
> Signed-off-by: Paul Durrant
> Cc: Stefano Stabellini
> Cc: Anthony Perard
> Cc: Paolo Bonzini
> ---
> xen-hvm.c | 12 ++--
> 1 file changed, 10 in
On 09/05/2016 18:14, Paul Durrant wrote:
>> -Original Message-
>> From: Paul Durrant
>> Sent: 09 May 2016 17:02
>> To: Paul Durrant; Paolo Bonzini; Martin Cerveny
>> Cc: xen-de...@lists.xensource.com; George Dunlap
>> Subject: RE: [Xen-devel] Over
On 28/04/2016 13:25, Paul Durrant wrote:
>> Maybe you are lucky, qemu is registered before your own demu
>> emulator.
>
> I guess I was lucky.
Yeah, QEMU has been doing that since 2013 (commit 3bb28b7, "memory:
Provide separate handling of unassigned io ports accesses", 2013-09-05).
>> I used
On 08/04/2016 18:00, Andy Lutomirski wrote:
> But %ss can be loaded with 0 on 64-bit kernels. (I assume that
> loading 0 into %ss sets SS.DPL to 0 if done at CPL0, but I'm vague on
> this, since it only really matters to hypervisor code AFAIK.)
It's even simpler, unless CPL=0 SS cannot be loade
On 14/03/2016 17:53, Andy Lutomirski wrote:
> > Please do the same for KVM.
>
> Can you clarify? KVM uses the native version, and the native version
> only oopses with this series applied if panic_on_oops is set.
Since you fixed the panic_on_oops thing, I'm okay with letting KVM use
the unsafe
On 14/03/2016 18:02, Andy Lutomirski wrote:
> On Mon, Mar 14, 2016 at 9:58 AM, Linus Torvalds
> wrote:
>>
>> On Mar 14, 2016 9:53 AM, "Andy Lutomirski" wrote:
>>>
>>> Can you clarify? KVM uses the native version, and the native version
>>> only oopses with this series applied if panic_on_oops
On 11/03/2016 20:06, Andy Lutomirski wrote:
> This adds paravirt hooks for unsafe MSR access. On native, they
> call native_{read,write}_msr. On Xen, they use
> xen_{read,write}_msr_safe.
>
> Nothing uses them yet for ease of bisection. The next patch will
> use them in rdmsrl, wrmsrl, etc.
>
On 27/01/2016 19:23, Olaf Hering wrote:
>
> xen.git/tools/qemu-xen-dir/hw/i386/intel_iommu.c: In function
> ‘vtd_context_device_invalidate’:
> xen.git/tools/qemu-xen-dir/hw/i386/intel_iommu.c:911:46: error: ‘mask’ may be
> used uninitialized in this function [-Werror=maybe-uninitialized]
>
On 21/01/2016 18:01, Stefano Stabellini wrote:
> -XEN_PT_LOG(&s->dev, "Failed to initialize %d/%ld reg
> 0x%x in grp_type=0x%x (%d/%ld), rc=%d\n",
> - j,
> ARRAY_SIZE(xen_pt_emu_reg_grps[i].emu_regs),
> -
On 02/12/2015 11:30, Paolo Bonzini wrote:
> diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h
> index f9998b9..87a4145 100644
> --- a/include/exec/cpu-all.h
> +++ b/include/exec/cpu-all.h
> @@ -174,11 +174,10 @@ extern unsigned long reserved_va;
> #defin
On 01/12/2015 18:53, Anthony PERARD wrote:
> The problem is in qemu_ram_alloc_internal() where 'size' and 'maxsize' are
> now been truncate to 32bit, due to 'qemu_host_page_size' been an uintptr_t
> in the HOST_PAGE_ALIGN macro.
Isn't it qemu_host_page_mask that causes the problem?
This should
On 19/11/2015 16:32, Stefano Stabellini wrote:
> > In addition to Kevin's replies, I have a high-level question: can VFIO
> > be used by QEMU for both KVM and Xen?
>
> No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
> is owned by Xen.
I don't think QEMU command line compa
On 19/11/2015 09:40, Gerd Hoffmann wrote:
>> > But this code should be
>> > minor to be maintained in libvirt.
> As far I know libvirt only needs to discover those devices. If they
> look like sr/iov devices in sysfs this might work without any changes to
> libvirt.
I don't think they will look
On 12/10/2015 13:09, Stefano Stabellini wrote:
> On Sun, 11 Oct 2015, Lan Tianyu wrote:
>> From: >
>>
>> msix->mmio is added to XenPCIPassthroughState's object as property.
>> object_finalize_child_property is called for XenPCIPassthroughState's
>> object, which calls object_property_del_all, whi
On 21/09/2015 19:43, Andy Lutomirski wrote:
> And maybe the KVM user return notifier.
No, not really. If anything, the place in KVM where it makes a
difference is vmx_save_host_state, which is also only using
always-present MSRs. But don't care about KVM.
First clean it up, then we can add ba
On 21/09/2015 10:46, Ingo Molnar wrote:
> Or we could extend exception table entry encoding to include a 'warning bit',
> to
> not bloat the kernel. If the exception handler code encounters such an
> exception
> it would generate a one-time warning for that entry, but otherwise not crash
> t
These have roughly the same purpose as the SMRR, which we do not need
to implement in KVM. However, Linux accesses MSR_K8_TSEG_ADDR at
boot, which causes problems when running a Xen dom0 under KVM.
Just return 0, meaning that processor protection of SMRAM is not
in effect.
Signed-off-by: Paolo
On 18/09/2015 15:54, Borislav Petkov wrote:
> On Thu, Sep 17, 2015 at 01:23:31PM -0700, Andy Lutomirski wrote:
>> > Cc: Borislav. Is TSEG guaranteed to exist? Can we defer that until
> Why not? It is the tseg base address.
>
> I think this is kvm injecting a #GP as it is not ignoring this MSR.
On 17/09/2015 17:27, Arjan van de Ven wrote:
>>
>>> ( We should double check that rdmsr()/wrmsr() results are never left
>>>uninitialized, but are set to zero or so, for cases where the
>>> return code is not
>>>checked. )
>>
>> It sure looks like native_read_msr_safe doesn't clear the ou
On 17/09/2015 17:31, Arjan van de Ven wrote:
>>
>> What about 0 + WARN?
>
> why 0?
>
> 0xdeadbeef or any other pattern (even 0x3636363636) makes more sense (of
> course also WARN... but most folks don't read dmesg for WARNs)
>
> (it's the same thing we do for list or slab poison stuff)
Sorry,
On 17/09/2015 17:26, Andy Lutomirski wrote:
> Maybe Paolo can fix QEMU to fail bad MSR accesses for real...
I was afraid of someone proposing exactly that. :)
I can do it since the list of MSRs can be lifted from KVM. Let's first
see the direction these patches go...
Paolo
__
On 17/09/2015 10:58, Peter Zijlstra wrote:
> But the far greater problem I have with the whole virt thing is that
> you cannot use rdmsr_safe() to probe if an MSR exists at all because, as
> you told me, these virt thingies return 0 for all 'unknown' MSRs instead
> of faulting.
At least for KVM,
On 17/09/2015 11:31, Borislav Petkov wrote:
>
>> > Crashing the bootup on an unknown MSR is bad. Many MSR reads and writes
>> > are
>> > non-critical and returning the 'safe' result is much better than crashing
>> > or
>> > hanging the bootup.
> ... and prepending all MSR accesses with featu
On 15/09/2015 15:28, Stefano Stabellini wrote:
>
>> > 2). Send an follow up patch to change this to abort()? (and wherever else
>> > I used
>> > assert(..)?
> Yes, that would be good.
>
>
>> > 3). Wait till Paolo is done going through the patchset and then revisit
>> > 1) or 2)?
> I d
On 15/09/2015 11:55, Stefano Stabellini wrote:
> On Mon, 14 Sep 2015, Paolo Bonzini wrote:
>> > On 10/09/2015 12:29, Stefano Stabellini wrote:
>>> > > +if (lseek(config_fd, pos, SEEK_SET) != pos) {
>>> > > +return -errno;
>>> >
On 10/09/2015 19:15, Stefano Stabellini wrote:
> +
> +switch (reg->size) {
> +case 1: rc = xen_host_pci_get_byte(&s->real_device, offset, (uint8_t
> *)&val);
A bit ugly, and it relies on the host being little endian.
> +break;
> +case 2: rc = xen_host_pc
On 10/09/2015 12:29, Stefano Stabellini wrote:
> +if (lseek(config_fd, pos, SEEK_SET) != pos) {
> +return -errno;
> +}
> do {
> -rc = pread(config_fd, (uint8_t *)&val, len, pos);
> +rc = read(config_fd, (uint8_t *)&val, len);
> } while (rc < 0 && (errno =
On 10/09/2015 16:24, Kevin Davis wrote:
> Further leading me to guess that any actual use of those
> implementations could lead to you actually needing to hire a real
> attorney and not one that you find on YouTube.
The good thing is that attorneys have already figured it out. IBM
figured out a
On 10/09/2015 08:57, Sharma Bhupesh wrote:
> So based on my limited understanding, can't the OVMF driver which
> uses features from some GPL based code, carry a dual license (GPL +
> x11 [MIT]),
No, that would require agreement from the original copyright holder,
which you are not going to get.
ten
Sent: Wednesday, September 09, 2015 12:58 PM
To: Andrew Fish
Cc: Lenny Szubowicz ; Karen Noel ; Ard
Biesheuvel ; edk2-devel-01
; Reza Jelveh ; Alexander Graf
; qemu devel list ; Hannes Reinecke
; Gabriel L. Somlo (GMail) ; Peter Jones
; Peter Batard ; Gerd Hoffmann
; Cole Robinson ; Paolo B
On 09/09/2015 13:07, Ian Campbell wrote:
> I have a question: What attack vector is setting the stack as Nx in OVMF
> (or even UEFI generally) trying to protect against? Or is this being done
> for a reason other than security?
>
> I understand why it is done for kernels and apps, but where does
On 29/07/2015 02:47, Andy Lutomirski wrote:
> > > If new kernels ignore the IOMMU for devices that don't set the flag
> > > and there are physical devices that already exist and don't set the
> > > flag, then those devices won't work reliably on most modern
> > > non-virtual platforms, PPC includ
On 28/07/2015 19:19, Jan Kiszka wrote:
> On 2015-07-28 19:15, Paolo Bonzini wrote:
>>
>>
>> On 28/07/2015 18:42, Jan Kiszka wrote:
>>>> On the other hand interrupt remapping is absolutely necessary for
>>>> production use, hence my point that x86 doe
On 28/07/2015 18:42, Jan Kiszka wrote:
> > On the other hand interrupt remapping is absolutely necessary for
> > production use, hence my point that x86 does not promise API stability.
>
> Well, we currently implement the features that the Q35 used to expose.
> Adding interrupt remapping will re
On 28/07/2015 15:11, Jan Kiszka wrote:
>>> >>
>>> >> This doesn't matter much, since the only guests that implement an IOMMU
>>> >> in QEMU are (afaik) PPC and x86, and x86 does not yet promise any kind
>>> >> of stability.
>> >
>> > Hmm I think Jan (cc) said it was already used out there.
> Yes
On 28/07/2015 12:12, Benjamin Herrenschmidt wrote:
>> > That is an experimental feature (it's x-iommu), so it can change.
>> >
>> > The plan was:
>> >
>> > - for PPC, virtio never honors IOMMU
>> >
>> > - for non-PPC, either have virtio always honor IOMMU, or enforce that
>> > virtio is not un
On 28/07/2015 03:08, Andy Lutomirski wrote:
> On Mon, Sep 1, 2014 at 10:39 AM, Andy Lutomirski wrote:
>> This fixes virtio on Xen guests as well as on any other platform
>> that uses virtio_pci on which physical addresses don't match bus
>> addresses.
>>
>> This can be tested with:
>>
>> vir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/06/2015 12:11, Stefano Stabellini wrote:
>>>
>>> Hopefully I will get to a change to Xen. However getting the
>>> Xen change back-ported to enough version(s) will not be
>>> quick...
> Yeah, this is basically an ABI breakage.
>
> We have b
On 15/05/2015 09:50, Markus Armbruster wrote:
> --nodefaults must continue to disable all optional parts of the board.
>
> What exactly is optional is for the board / machine type to define. It
> can't be changed once the machine type is released.
>
> When in doubt, make it optional.
I agree
On 14/05/2015 16:41, Stefano Stabellini wrote:
> Do not change default settings for any machines at the moment: this
> patch does not introduce any changes in behavior unless the user asks
> for no-fdc=on.
Can we avoid the double negative?
Paolo
> Signed-off-by: Stefano Stabellini
> ---
> hw
On 14/05/2015 16:39, Stefano Stabellini wrote:
> On Thu, 14 May 2015, Paolo Bonzini wrote:
>> On 14/05/2015 15:25, Sander Eikelenboom wrote:
>>> I tend to kindly disagree if you look at the broader perspective, yes it's
>>> could
>>> be a storm in a
On 14/05/2015 15:25, Sander Eikelenboom wrote:
> I tend to kindly disagree if you look at the broader perspective, yes it's
> could
> be a storm in a tea cup, but there seems to be a pattern.
>
> From a "cmdline user" / "platform emulation" point of view i can imagine that
> some sort of
> a
On 14/05/2015 14:45, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 14/05/2015 14:02, Markus Armbruster wrote:
>>> It should certainly be off for pc-q35-2.4 and newer. Real Q35 boards
>>> commonly don't have an FDC (depends on the Super I/O c
On 14/05/2015 14:02, Markus Armbruster wrote:
> It should certainly be off for pc-q35-2.4 and newer. Real Q35 boards
> commonly don't have an FDC (depends on the Super I/O chip used).
>
> We may want to keep it off for pc-i440fx-2.4 and newer. I doubt
> there's a real i440FX without an
On 14/05/2015 13:47, Michael S. Tsirkin wrote:
> > I would be OK with a new property too, as we could set it from
> > libxl or libvirt. Anybody would be happy to pick this one up or should I
> > do it?
>
> Pls go ahead, I can merge it in the pc tree.
Note that because of the "-drive if=none,id=f
On 15/04/2015 16:14, Li, Liang Z wrote:
> Yes, it's the right place. Put aside the bug fix, I think the
> memory_region_ref/unref pair
> should be move to xen_pt_region_update after the conditional as you point
> out.
> Do you think so?
It would make sense, but I was just guessing... I'm s
On 13/04/2015 16:12, Liang Li wrote:
> 2. Do the attach and detach operation with a time interval. eg. 10s.
>
> The error message will not disappear if retry, in this case, it's
> a bug.
>
> In the 'xen_pt_region_add' and 'xen_pt_region_del', we should only care
> about the 'xen-pc
On 25/03/2015 10:44, Andrew Jones wrote:
> 2) create a specific DT node that will get exposed through sysfs, or
>somewhere.
Looking at custom DT nodes is what PowerPC does.
Paolo
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen
On 31/12/2014 00:02, Quan Xu wrote:
> Signed-off-by: Quan Xu
> ---
> configure| 14 ++
> hmp.c| 7 +++
> qapi-schema.json | 19 ---
> qemu-options.hx | 13 +++--
> tpm.c| 7 ++-
> 5 files changed, 54 insertions(+), 6
1 - 100 of 112 matches
Mail list logo
