>
> On Jun 4, 2020, at 2:03 PM, Jim Mattson wrote:
>
> On Thu, Jun 4, 2020 at 12:09 PM Nakajima, Jun wrote:
>
>> We (Intel virtualization team) are also working on a similar thing,
>> prototyping to meet such requirements, i..e "some level of confidentiality
>
> On Jun 4, 2020, at 9:35 AM, Will Deacon wrote:
>
> Hi Sean,
>
> On Thu, Jun 04, 2020 at 08:48:35AM -0700, Sean Christopherson wrote:
>> On Thu, Jun 04, 2020 at 04:15:23PM +0100, Marc Zyngier wrote:
>>> On Fri, 22 May 2020 15:51:58 +0300
>>> "Kirill A. Shutemov" wrote:
>>>
== Backgrou
On 5/13/19, 7:43 AM, "kvm-ow...@vger.kernel.org on behalf of Alexandre Chartre"
wrote:
Proposal
To handle both these points, this series introduce the mechanism of KVM
address space isolation. Note that this mechanism completes (a)+(b) and
don't contradict. In ca
> On Jan 22, 2016, at 7:56 AM, Rik van Riel wrote:
>
> Hi,
>
> I am trying to gauge interest in discussing VM containers at the LSF/MM
> summit this year. Projects like ClearLinux, Qubes, and others are all
> trying to use virtual machines as better isolated containers.
>
> That changes some o
On Wed, Sep 2, 2015 at 3:38 PM, Steve Rutherford wrote:
> On Thu, Aug 13, 2015 at 09:31:48AM +0200, Paolo Bonzini wrote:
> Pinging this thread.
>
> Should I put together a patch to make split irqchip work properly with the
> old TMR behavior?
Yes, please.
Intel® 64 and IA-32 Architectures Softw
Joerg Roedel wrote:
> Hi,
>
> here is the first release of patches for KVM to support the Nested
Paging
> (NPT) feature of AMD QuadCore CPUs for comments and public testing.
This
> feature improves the guest performance significantly. I measured an
> improvement of around 17% using kernbench in my
Joerg Roedel wrote:
> To disable the use of the Nested Paging feature even if it is
available in
> hardware this patch adds a module parameter. Nested Paging can be
disabled by
> passing npt=off to the kvm_amd module.
I think it's better to use a (common) parameter to qemu. That way you
can contro
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > Yes. For the native, "safe_halt" is "sti; hlt". The "native_halt" is
> > just "hlt". So the para_virt part of "hlt" could be moved to
pv_cpu_ops,
> > and the "sti&quo
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > Jeremy Fitzhardinge wrote:
> >
> >
> > > + .pv_irq_ops = {
> > > + .init_IRQ = native_init_IRQ,
> > > + .save_fl = native_save_fl,
> > > + .rest
Jeremy Fitzhardinge wrote:
> This patch refactors the paravirt_ops structure into groups of
> functionally related ops:
>
> pv_info - random info, rather than function entrypoints
> pv_init_ops - functions used at boot time (some for module_init too)
> pv_misc_ops - lazy mode, which didn't fit wel
Anthony Liguori wrote:
> This patch refactors the current hypercall infrastructure to better
support
> live
> migration and SMP. It eliminates the hypercall page by trapping the
UD
> exception that would occur if you used the wrong hypercall instruction
for the
> underlying architecture and repla
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
>
> > Again, 0x4000 is not Xen specific. If the leaf 0x4000 is
used
> > for any guest to detect any hypervisor, that would be compelling
> > benefit. For future Xen-specific features, it's safe for Xen to use
Anthony Liguori wrote:
> Nakajima, Jun wrote:
> >
> > I'm suggesting that we use CPUID.0x400Y (Y: TBD, e.g. 6) for
Linux
> > paravirtualization. The ebx, ecx and edx return the Linux
> > paravirtualization features available on that hypervisor. Those
features
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > The hypervisor detection machanism is generic, and the signature
> > returned is implentation specific. Having a list of all hypervisor
> > signatures sounds fine to me as we are detecting vendor-specific
> > proces
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > Today, 3 CPUID leaves starting from 0x4000_ are defined in a
generic
> > fashion (hypervisor detection, version, and hypercall page), and
those
> > are the ones used by Xen today. We should extend those leaves (e
Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > > > one. Start the kvm leaves at 0x40001000 or something?
> > > >
> > > >
> > > Yeah, that works with me.
> > >
> >
> > To me this is the beginning of fragmentation. W
Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
> > Anthony Liguori wrote:
> >
> > > Yeah, see, the initial goal was to make it possible to use the KVM
> > > paravirtualizations on other hypervisors. However, I don't think
this
> > > is really going to be possible in general so maybe it's bet
Glauber de Oliveira Costa wrote:
> On 8/8/07, Nakajima, Jun <[EMAIL PROTECTED]> wrote:
> > Glauber de Oliveira Costa wrote:
> > > Hi folks,
> > >
> > > After some time away from it, and a big rebase as a consequence,
here is
> > > the upd
Glauber de Oliveira Costa wrote:
> Hi folks,
>
> After some time away from it, and a big rebase as a consequence, here
is
> the updated version of paravirt_ops for x86_64, heading to inclusion.
>
> Your criticism is of course, very welcome.
>
> Have fun
Do you assume that the kernel ougtht to u
Ingo Molnar wrote:
> * Nakajima, Jun <[EMAIL PROTECTED]> wrote:
>
>> I think a KVM Linux would benefit more from paravirt ops, rather than
>> VMI. The higher-level interface such as the one in Xen, espeically
>> for I/O, interrupt controllers, timer, SMP, e
Anthony Liguori wrote:
> Ingo Molnar wrote:
>> * Gerd Hoffmann <[EMAIL PROTECTED]> wrote:
>>
> So in the end you would still have two different hypervisor ABI's,
> the VMI ROM just hides that.
oh, but that way i have cleverly pushed the problem out of Linux
and into the VMI-ROM's
21 matches
Mail list logo
